app macro doesn't work very well with rust-analyzer #582
Comments
|
Yea, I saw this problem as well, I thought my I had a quick look at the linked discussion, and it seems that the initial idea was to put the burden on the proc macro implementer (to parse the inner in detail) not sure we want to do that. Right now we just re-emit any tokens that are unknown to RTIC, which I think is the sensible thing to do atm. In #11014 it was also discussed other potential solutions requiring work on the actual rust-analyzer. So I'm not sure if we want/can do anything about this for the time being. I agree however that it is less than optimal that the whole module becomes squiggled while typing, its a lot of noise. /Per |
|
This seems odd, I do not get this problem with rust-analyzer. It correctly highlights the macro error as we would in a build: The same with code errors: |
|
I'm using this config to reduce the annoyance of this issue: "rust-analyzer.procMacro.enable": true,
"rust-analyzer.experimental.procAttrMacros": false,
"rust-analyzer.diagnostics.disabled": [
"macro-error"
], |
|
We should definitely shrink the error span here, that can be done without fixing the whole ecosystem |
11238: fix: shrink the span of errors from attribute macros and derives r=jonas-schievink a=jonas-schievink Some procedural macros tend to get very large invocations, for example RTIC's, leading to issues like rtic-rs/cortex-m-rtic#582, where almost the entire screen is underlined while editing incomplete code in the macro. This PR shrinks the spans of errors from attribute macros and derives to point only at the attribute, which also matches rustc more closely. bors r+ Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11238: fix: shrink the span of errors from attribute macros and derives r=jonas-schievink a=jonas-schievink Some procedural macros tend to get very large invocations, for example RTIC's, leading to issues like rtic-rs/cortex-m-rtic#582, where almost the entire screen is underlined while editing incomplete code in the macro. This PR shrinks the spans of errors from attribute macros and derives to point only at the attribute, which also matches rustc more closely. bors r+ Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
2022.01.10 11238: fix: shrink the span of errors from attribute macros and derives r=jonas-schievink a=jonas-schievink Some procedural macros tend to get very large invocations, for example RTIC's, leading to issues like rtic-rs/cortex-m-rtic#582, where almost the entire screen is underlined while editing incomplete code in the macro. This PR shrinks the spans of errors from attribute macros and derives to point only at the attribute, which also matches rustc more closely.
i've been writing a decently large embedded system to control a dsp and display a vumeter, however i was not particularly happy with how the rust language server integrates with vscode, so i switched to rust analyzer.
the change has been good, and things in general work a lot better, however there's one annoying problem: if i start typing anything at all inside of the app macro the entire screen turns red as everything following that attribute macro is considered a compiler error.
i've not written a proc macro myself, but here the rust analyzer devs talk about how this problem can be fixed by the macro developer in at least some cases:
rust-lang/rust-analyzer#11014
right now i'm considering externing everything out of the macro just so i can avoid this little problem. which both seems fun, but also extremely pointless.
i thought it worth bringing up in case you were not aware of this and it can be fixed. it seems as tho fixing this in rust analyzer may not be possible in the short term as they have a lot of considerations to make.
The text was updated successfully, but these errors were encountered: