Ensure that you are using an AVR target!

[eflukx]

Installed template as documented (for Arduino Uno), builds fine, no problems!

But rust-analyzer doesn't really like it and chokes on Ensure that you are using an AVR target!

[Rahix]

Hm, probably means that rust-analyzer attempts building for your host architecture instead of AVR? Does it not pick up the .cargo/config.toml file? In there, you should have a

[build]
target = "avr-something"

section to tell cargo to automatically build for AVR.

[eflukx]

I'm using the template unchanged (configured for Arduino Uno), my config.toml reads

[build]
target = "avr-specs/avr-atmega328p.json"

[target.'cfg(target_arch = "avr")']
runner = "ravedude uno -cb 57600"

[unstable]
build-std = ["core"]

Any avr-hal or arduino-hal example I tried, gave me the same issue with rust analyzer somehow...

As a sidenote: when I was looking for the correct avr-arch-triplet, I found that running `rustup target list' does not include any AVR target. (This is probably normal for AVR, needing a custom targetr spec .json file...)

[Rahix]

[build]
target = "avr-specs/avr-atmega328p.json"

Hm, this looks as expected... I never had any issues with this, can you somehow introspect what your rust-analyzer picked up?

As a sidenote: when I was looking for the correct avr-arch-triplet, I found that running `rustup target list' does not include any AVR target. (This is probably normal for AVR, needing a custom targetr spec .json file...)

Yeah, that is expected: There is no prebuilt libcore for AVR, it is always build with cargo -Zbuild-std on demand for each project.

[eflukx]

I've extracted some trace logging from Rust analyzer (by setting the "rust-analyzer.trace.server": "verbose" config option), frankly I'm doubtful how useful this log is.. Anyway, here it is: https://gist.github.com/eflukx/9b676ec4fe8045c95e79d17e1515b832

I'm running on nightly version of RA, maybe I can try a version that is known-working? Are there people experiencing the same problem?

[Rahix]

Interesting, just tried and I can reproduce this with latest r-a. For me, it looks like rust-analyzer b73b32147 2021-09-06 dev still works fine. Maybe you can try bisecting it down further? I would assume that this is a regression in r-a...

[eflukx]

I manually tried different versions of the rust-analyzer VSCode plugin v0.2.760 is the last version that seem to work correctly, from v0.2.768 onwards, the problem arises.

I wasn't able to quickly find how the r-a commit hash (or tag name) maps to the VSCode plugin version, so I do not know which which commits are causing the problem.

[eflukx]

Ok, the bug/issue is identified on rust analyzer: https://github.com/rust-analyzer/rust-analyzer/issues/10753#issuecomment-968278541

Thanks @Rahix for thinking along!

tl;dr: disable the rust-analyzer.experimental.procAttrMacros setting for a quick fix/workaround in the mean time.