Attribute proc-macro expansion issue

[liuw]

Commit 81891f7 enabled attribute proc macro by default (released in v0.2.768). That rendered rust-analyzer unusable in my case. Basically whenever I change something, the whole function is marked as problematic. Please see the two screenshots for comparison.

First screenshot shows the result when that option is enabled; second screenshot shows the result when the option is disabled.

In the second screenshot, rust-analyzer correctly points out that let x is problematic.

[flodiebold]

Can you provide the crate where the macro comes from and ideally some example code?

The problem is likely that the proc macro emits an error when the function is syntactically invalid. (What error message does rustc emit when faced with this incomplete code?) In that case, probably your only options are to either report this to the proc macro authors and wait for them to fix it, or to disable attribute macro expansion again.

[Veykril]

The crate is legion I believe

[liuw]

Can you provide the crate where the macro comes from and ideally some example code?

Like @Veykril said, the crate is legion. It not straight-forward for me to provide a minimal repro. The code is at https://github.com/amethyst/legion/blob/32df916517fa3b3bb5d827d824053bbb128a43be/codegen/src/lib.rs#L159.

The problem is likely that the proc macro emits an error when the function is syntactically invalid. (What error message does rustc emit when faced with this incomplete code?) In that case, probably your only options are to either report this to the proc macro authors and wait for them to fix it, or to disable attribute macro expansion again.

Please see the screenshot for the error message. Yes it is complaining about invalid syntax, but that's not very helpful in identifying the root cause.

[liuw]

If this is helpful, this is what I get when running cargo c. It is able to pinpoint the correct location of the incomplete code.

[flodiebold]

Hm. The first error comes from rustc's parser; does the second one come from the macro? If so, how does rustc know the location? Does rustc even try to expand the macro if there's a syntax error in the input? 🤔

[flodiebold]

Ah, syn sets the span of the compile_error! invocation to be the error span. Probably we don't handle that correctly when mapping errors up?

Edit: But actually, with a test proc macro it seems to be working fine 🤔

[lucacasonato]

+1 on this. I also happens with the #[tokio::test] and #[tracing::instrument] macros.

[bjorn3]

Tracing: tokio-rs/tracing#1633
Tokio: tokio-rs/tokio#4154 (fixed on master)

[lucacasonato]

Beautiful, thank you for the hard work everyone ❤️

[Follpvosten]

So this is an issue of the specific proc macro implementation, right? So if I notice it with any other macros (like in actix or async-graphql...), I should prefer reporting it to them?

[lnicola]

If it's the same issue, you could, e.g. actix/actix-web#2394.

[asdrubalinea]

I'm having the same issue with the async-trait macros, should I report it there?

[Veykril]

Yep, that should have the problem as well, https://github.com/dtolnay/async-trait/blob/70bdfa4a8035393164a79391fdb862acc3310c66/src/lib.rs#L334-L335, so reporting that issue there would be a good idea.