Skip to content

RA doesn't seem to respect cfg on fields #4063

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Lokathor opened this issue Apr 20, 2020 · 6 comments
Closed

RA doesn't seem to respect cfg on fields #4063

Lokathor opened this issue Apr 20, 2020 · 6 comments

Comments

@Lokathor
Copy link

pub struct ZlibByteIter<'s> {
  pub(crate) current: &'s [u8],
  pub(crate) idat_iter: IdatIter<'s>,
  #[cfg(not(feature = "png_skip_adler_checks"))]
  pub(crate) adler: u32,
}

impl<'s> ZlibByteIter<'s> {
  fn from_current_and_iter(current: &'s [u8], idat_iter: IdatIter<'s>) -> Self {
    #[cfg(not(feature = "png_skip_adler_checks"))]
    {
      Self { current, idat_iter, adler: 1 }
    }
    #[cfg(feature = "png_skip_adler_checks")]
    {
      Self { current, idat_iter }
    }
  }
}

This will report the second cfg variant as missing the adler field, which doesn't exist under that configuration.

@bjorn3
Copy link
Member

bjorn3 commented Apr 20, 2020

I think this should have been fixed by #3880, but that PR was merged 11 days ago.

@Lokathor
Copy link
Author

It seems I have, rust-analyzer version: 2020-04-13 (c388130), which is newer than 11 days ago if my math is right

@edwin0cheng
Copy link
Member

which doesn't exist under that configuration.

What's your rust-analyzer.cargo.features settings ?

@flodiebold
Copy link
Member

I think the problem might rather be that we don't support cfg on blocks (or do we?) 🤔

@bnjjj
Copy link
Contributor

bnjjj commented Apr 25, 2020

For now cfg is partially supported on struct fields, and function as far as I remember. And when I say partially it's mainly because it just check the default features in your cargo.toml. I think it should work with this kind of syntax:

pub struct ZlibByteIter<'s> {
  pub(crate) current: &'s [u8],
  pub(crate) idat_iter: IdatIter<'s>,
  #[cfg(not(feature = "png_skip_adler_checks"))]
  pub(crate) adler: u32,
}

impl<'s> ZlibByteIter<'s> {
  fn from_current_and_iter(current: &'s [u8], idat_iter: IdatIter<'s>) -> Self {
      Self {
          current,
          idat_iter,
          #[cfg(not(feature = "png_skip_adler_checks"))]
          adler: 1
     }
  }
}

Or you can also have 2 methods fn from_current_and_iter(current: &'s [u8], idat_iter: IdatIter<'s>) -> Self on with the feature flag enabled and another one without. Because for now we don't support cfg attributes on block.

I will try to implement it in the next days :)

@Lokathor let me know if these workarounds are working :)

bnjjj added a commit to bnjjj/rust-analyzer that referenced this issue Apr 25, 2020
bors bot added a commit that referenced this issue Apr 25, 2020
4113: Support returning non-hierarchical symbols r=matklad a=kjeremy

If `hierarchicalDocumentSymbolSupport` is not true in the client capabilites
then it does not support the `DocumentSymbol[]` return type from the
`textDocument/documentSymbol` request and we must fall back to `SymbolInformation[]`.

This is one of the few requests that use the client capabilities to
differentiate between return types and could cause problems for clients.

See microsoft/language-server-protocol#538 (comment) for more context.

Found while looking at #144

4136: add support for cfg feature attributes on expression #4063 r=matklad a=bnjjj

close issue #4063

4141: Fix typo r=matklad a=Veetaha



4142: Remove unnecessary async from vscode language client creation r=matklad a=Veetaha



4145: Remove dead code r=matklad a=matklad



bors r+
🤖

Co-authored-by: kjeremy <[email protected]>
Co-authored-by: Benjamin Coenen <[email protected]>
Co-authored-by: veetaha <[email protected]>
Co-authored-by: Aleksey Kladov <[email protected]>
bors bot added a commit that referenced this issue Apr 25, 2020
4113: Support returning non-hierarchical symbols r=matklad a=kjeremy

If `hierarchicalDocumentSymbolSupport` is not true in the client capabilites
then it does not support the `DocumentSymbol[]` return type from the
`textDocument/documentSymbol` request and we must fall back to `SymbolInformation[]`.

This is one of the few requests that use the client capabilities to
differentiate between return types and could cause problems for clients.

See microsoft/language-server-protocol#538 (comment) for more context.

Found while looking at #144

4136: add support for cfg feature attributes on expression #4063 r=matklad a=bnjjj

close issue #4063

4141: Fix typo r=matklad a=Veetaha



4142: Remove unnecessary async from vscode language client creation r=matklad a=Veetaha



Co-authored-by: kjeremy <[email protected]>
Co-authored-by: Benjamin Coenen <[email protected]>
Co-authored-by: veetaha <[email protected]>
@lnicola
Copy link
Member

lnicola commented Apr 25, 2020

Closed by #4063.

@lnicola lnicola closed this as completed Apr 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants