rust-analyzer: Autocomplete degradation

it seems that we never should asks to adjust “valid” cases, except for what be great for rustc as well (eg, using proper spans)

for invalid and “incomplete” cases, I feel that we fundamentally need help from proc macros, and here the strategy works OK

I do not agree that rust-analyzer fundamentally can’t do better on syntactically invalid attribute macro input.

Rust-analyzer currently passes unmodified syntactically invalid input as macro input into attribute macros. In my opinion this violates the contract of attribute macros, which are required to be written on a valid AST node, regardless of what the macro does.

[Rustc also currently passes invalid syntax, but it’s a recent regression which we plan to fix, with the approach described in the comments under https://github.com/rust-lang/rust/issues/76360#issuecomment-951145592.]

Passing syntactically invalid input to attribute macros, whether in the context of rustc or rust-analyzer, is not a good plan because doing the recovery, emitting diagnostics about the recovery, and then running macros on the original unrecovered input means that in general you’re forcing macros to reimplement their own recovery independent and inconsistent with rustc/rust-analyzer — so rustc/rust-analyzer will diagnose what it thinks you meant, and the macro will diagnose what it thinks, and probably they won’t align, resulting in dissonant user-facing messages. The correct behavior in my opinion is for rustc/rust-analyzer to perform its normal high-effort syntax recovery the same as for nodes that are not macro input, report diagnostics on that recovery as normal, then pass the recovered input for the attribute to proceed on.

Recovery in this context would involve rust-analyzer snipping out the nearest syntactically invalid syntax tree node and swapping in whatever syntactically valid placeholder/sentinel it wants in its place. It can then run the macro which will expand successfully, then provide autocompletion and other functionality to the programmer based on the position where it finds its sentinel in the expanded output, and the original snipped out syntax.

While the user is typing inside of attribute macro input this approach will give high quality results for the IDE in vastly more cases than rust-analyzer’s current behavior, without trying to force changes for invalid macro input into all the attribute macros in the ecosystem.

This is due to the newest version enabling attribute macro expansion by default, as such completion doesn’t work properly in actix_web::main attributed functions anymore because the proc-macro emits an error instead of recovering on a parse error(it fails to parse the function as you now have an invalid statement while typing in the middle of it).

So you can either lift your code out of the main function into a new one so that you don’t need to type in the attributed function or set "rust-analyzer.experimental.procAttrMacros" :false in your settings.

I guess we can start with a shared hackmd between IJ and RA teams, and then rope proc macro folks in?

This sounds like the best step to me for now, noting down what we know about the current state of things might give us some better insight on how to address this.

This is due to the newest version enabling attribute macro expansion by default, as such completion doesn’t work properly in actix_web::main attributed functions anymore because the proc-macro emits an error instead of recovering on a parse error(it fails to parse the function as you now have an invalid statement while typing in the middle of it).

So you can either lift your code out of the main function into a new one so that you don’t need to type in the attributed function or set "rust-analyzer.experimental.procAttrMacros" :false in your settings.

it’s worked