analyzer: code is inactive due to #[cfg] directives: doc is disabled

[nipunn1313]

The inactive-code check appears to false positive (IMO) on #[cfg(doc)].

Sample code

#[cfg(doc)]
use std::future::Future;

/// Handy struct that pairs well with [`Future`].
pub struct Past;

One could potentially argue that this is behaving-as-designed, since it's analyzing the code, but not the docs - but I found it a bit un-useful.

Some possible proposed solutions

• not include cfg(doc) code blocks in the inactive-code analyzer.
• Include docstrings in the analyzer
  Open to other ideas to solve.

[bjorn3]

Rust-analyzer can only analyze one cfg() configuration at a time. Any code inside an inactive #[cfg] will have most ide functionality like autocompletion, rust-analyzer native diagnostics and inlay hints disabled. We have a warning to prevent confusion about why ide functionality doesn't work in these blocks.

[nipunn1313]

cool - that makes sense. It's a bit of a bummer, but an understandable one.
Out of curiosity, what does rust-analyzer use as a default cfg?

[bjorn3]

I believe it uses the default of rustc for the respective target + all features enabled when the root is compiled with --all-features + cfg(test) (unless the rust-analyzer.cargo.unsetTest config contains the name of the respective crate).

[nipunn1313]

Is there an easy way to enable --all-features + cfg(test) + cfg(doc) ?

I tried setting --cfg doc in cargo.extraEnv but it seemed to disable some of the other cfgs (like proc macro)

doc feel like a special language-endorsed cfg (like test) and I wonder if there's a discussion/argument for including it in the default.

[threema-donat]

I'm also looking for a way to enable all features, since rust-analyzer.cargo.allFeatures apparently does not exist anymore (as suggested here).

[bjorn3]

You can set rust-analyzer.cargo.features to "all" rather than an array of features to enable all features.

[nine9ths]

When I set "rust-analyzer.cargo.features": ["all"] in VS Code I get the following error:

[ERROR rust_analyzer::main_loop] FetchWorkspaceError:
rust-analyzer failed to load workspace: Failed to load the project at ...snip.../rust/Cargo.toml: Failed to read Cargo metadata from Cargo.toml file ...snip.../rust/Cargo.toml, Some(Version { major: 1, minor: 71, patch: 0 }): Failed to run `cd "...snip.../rust" && "cargo" "metadata" "--format-version" "1" "--features" "all" "--manifest-path" "...snip.../rust/Cargo.toml" "--filter-platform" "aarch64-apple-darwin"`: `cargo metadata` exited with an error: error: none of the selected packages contains these features: all

If I set it to a specific feature it seems to work fine. Not sure what I'm missing.

[flodiebold]

@nine9ths Try "rust-analyzer.cargo.features": "all".

[jcalabro]

Perhaps there could be something similar to #[allow(dead_code)] for circumstances such as these? It's really nice to have no noise from linters in the editor.

[keks]

Any code inside an inactive #[cfg] will have most ide functionality like autocompletion, rust-analyzer native diagnostics and inlay hints disabled. We have a warning to prevent confusion about why ide functionality doesn't work in these blocks.

By that logic we'd also have to have a warning in every function guarded by a proc-macro, because a lot of features also don't work in there. I think we can agree that having that would be nonsense, so I am not convinced that this is a good reason.

Perhaps there could be something similar to #[allow(dead_code)] for circumstances such as these? It's really nice to have no noise from linters in the editor.

Since the name of the reported diagnostic seems to be inactive-code, it seems like #[allow(inactive-code)] would make most sense (though I am not sure why it is kebab-case instead of snail-case, and whether that would be an issue)

[ChayimFriedman2]

Any code inside an inactive #[cfg] will have most ide functionality like autocompletion, rust-analyzer native diagnostics and inlay hints disabled. We have a warning to prevent confusion about why ide functionality doesn't work in these blocks.

By that logic we'd also have to have a warning in every function guarded by a proc-macro, because a lot of features also don't work in there. I think we can agree that having that would be nonsense, so I am not convinced that this is a good reason.

IDE features work fine in proc macros (albeit sometimes they can be slower). The only exception I can think of is inlay hints which are intentionally disabled. Also, it's clear when a code is inside a macro, but not when a cfg is disabled.

Perhaps there could be something similar to #[allow(dead_code)] for circumstances such as these? It's really nice to have no noise from linters in the editor.

Since the name of the reported diagnostic seems to be inactive-code, it seems like #[allow(inactive-code)] would make most sense (though I am not sure why it is kebab-case instead of snail-case, and whether that would be an issue)

Having kebab case will indeed be a problem (although it's solvable). Perhaps rust_analyzer::inactive_code will be fine. But if it's a problem for you, you can disable it globally.