Set `RUST_IDE_PROC_MACRO_COMPLETION` and `RUST_IDE_PROC_MACRO_COMPLETION_DUMMY_IDENTIFIER` for proc macros

[lnicola]

CC intellij-rust/intellij-rust#9711, yewstack/yew#2972

[Veykril]

The way this is done I think will break for r-a due to how our completions work 😕 We expand proc-macros twice, once properly and once speculatively(this is where we would set the env vars), but the infra falls down if the expansions start to differ in structure too much I believe. We also would need to re-expand the non-speculative one for completions which seems not necessarily ideal.

[flodiebold]

Yeah, gating error resilience behind a special flag is the opposite of helpful :/ The dummy identifier thing we can do though.

[vlad20012]

Btw in IntelliJ Rust we also expand proc-macros twice, but use for completion purposes only speculatively run (with dummy identifier inserted). I think we could use both as well, but I'd anyway set environment variables only during the speculative run.

[Veykril]

The problem is we can't use the speculative one for semantic analysis due to how salsa works, thats where the original expansion comes in. And therefor if the two expansions differ too much we run into problems (which tbf already happens in some scenarios where in the original expansion an identifier is missing)

[vlad20012]

And therefor if the two expansions differ too much we run into problems (which tbf already happens in some scenarios where in the original expansion an identifier is missing)

Could you explain this a little more? I think this is absolutely not a problem for IntelliJ Rust, in out case they can differ in any way.

[flodiebold]

I don't understand the notion that error resilience is only necessary for completion anyway. We also want e.g. go to definition to work in an incomplete macro.

[vlad20012]

The main idea behind it is custom completion, not error resilience. For example, standard tag name completion in yew (div, span, etc), or attribute names completion in yew (<div st/*caret*/>). I only did the basic PoC in yew which looks like error resilience at first glance, but in general the idea is a custom completion

[vlad20012]

Also,

1. changing the macro behavior explicitly for IDE purposes should be more psychologically comfortable for proc macro authors
2. returning the expansion in addition to compile_error!() goes against usual architecture of syn-based proc macros and leads to lot of code changes; hence this is another source of discomfort and doubt for proc macro authors, I guess

[flodiebold]

We're all for supporting custom completions, but that only requires RUST_IDE_PROC_MACRO_COMPLETION_DUMMY_IDENTIFIER.

changing the macro behavior explicitly for IDE purposes should be more psychologically comfortable for proc macro authors

I don't know if that's true. But "for IDE" and "for completions" are still different; I can somewhat see the point of letting the proc macro know it's running in an IDE, but then we would set the variable all the time and not just for completions. Which might be what ends up happening if enough macros do gate error resilience on the variable.

returning the expansion in addition to compile_error!() goes against usual architecture of syn-based proc macros and leads to lot of code changes; hence this is another source of discomfort and doubt for proc macro authors, I guess

I don't know how the RUST_IDE_PROC_MACRO_COMPLETION variable helps with that, you have to implement the error resilience either way. I think the usual architecture of syn-based proc macros is just bad for IDEs, and there's not much we can do about it (for function-based proc macros).