Open zjp-CN opened 2 months ago
Hmm, the attributes are configured at that point, so the issue is probably in https://github.com/rust-lang/rust-analyzer/blob/0c795a7226a9cb2267c56d2f46aee698b8c78f78/crates/hir-expand/src/attrs.rs#L127-L156 somewhere
As a sidenote, I find embassy codebase uses conditional compilation a lot by combining cfg_attr and path attribute macro .
So a similar case worth considering is like this:
#[cfg(feature = "_arch")]
#[cfg_attr(feature = "arch-avr", path = "arch/avr.rs")]
#[cfg_attr(feature = "arch-cortex-m", path = "arch/cortex_m.rs")]
#[cfg_attr(feature = "arch-riscv32", path = "arch/riscv32.rs")]
#[cfg_attr(feature = "arch-std", path = "arch/std.rs")]
#[cfg_attr(feature = "arch-wasm", path = "arch/wasm.rs")]
mod arch;
RA mistakenly recognizes arch/avr.rs as arch module file, when arch-riscv32
feature is enabled in the RA configuration file.
Wow, this pattern causes 1K+ errors in embassy-hal-internal without enabling any feature in it.
(I could try to solve this issue, but don't have the time until next month.)
Edit: wait, cfg_attr is not the evil, they are caused by cfg attributes instead 😮
Hmm those are rustc errors though, not rust-analyzer? This sounds like your cargo check
for rust-analyzer is setup wrongly
Do you have "rust-analyzer.cargo.features"
/ "rust-analyzer.check.features"
set to "all"
?
Do you have
"rust-analyzer.cargo.features"
/"rust-analyzer.check.features"
set to"all"
?
No, I never have them in configuration file. That's what surprises me.
Weird, these cfg error doesn't exist on vscode. embassy has own vscode settings which I didn't use in neovim.
I have to double check on my RA settings.
Well, there are some interesting things going on:
cargo.allFeatures
is enabled by neovim RA plugin mrcjkb/rustaceanvim
"rust-analyzer.cargo.allFeatures": false
, the problem in the original issue on #[cfg_attr(feature = "gated", path = "submod_gated.rs")]
is gone. I believe the 1K+ errors in embassy-hal-internal will also disappear, though I haven't tested it.cargo.allFeatures
seems deprecated since https://github.com/rust-lang/rust-analyzer/pull/12010 , but it's still working. What if we both have a setting like this?{
"rust-analyzer.cargo.features": [],
"rust-analyzer.cargo.allFeatures": true,
}
It's valid, and RA only respects the second and causes the issue.
allFeatures
is not mentioned in the manual page any more, can RA stops recognizing it?
If allFeatures
has to be kept, I think the documentation needs improvement which I can help.
can RA stops recognizing it?
I'd love to do that but some of the third party clients have complained about us fixing up the config so we had to still accept that setting. We could maybe try removing that compat layer now. Accepting that is just a backwards compat change.
The bigger issue here is that https://github.com/mrcjkb/rustaceanvim/tree/master has a very bad default for that config here. There is a reason why allFeatures
is disabled by default because crates tend to use non-additive features.
See https://github.com/rust-lang/rust-analyzer/issues/4604#issuecomment-1117235051 and the following collapsed comments
We could maybe just warn in the logs and the like if a client sends outdated config keys that are still accepted for now
rust-analyzer version: rust-analyzer 1.80.0-nightly (7c52d2d 2024-06-03)
rustc version: rustc 1.80.0-nightly (7c52d2db6 2024-06-03)
editor or extension: neovim
relevant settings: None
repository link (if public, optional): None. But I found the problem from embassy-executor. For reproducible code, see below.
code snippet to reproduce:
Currently, RA marks
submod.rs
asfile not included in crate hierarchy
whengated
feature is nowhere enabled, and treatssubmod_gated.rs
as the default submod file, discardingcfg_attr
.