I try to write a language server, then edit rust analyzer code so when cursor in fn macro it will forward TokenTree to language server.
New RustRover can give suggestion in sqlx string. I think this is similar to what I want in macro complete, but I don't know how intellij did it.
RustRover doesn't use rust-analyzer; they have their own language-awareness system.
There's a discussion about it in this open issue, so maybe you can weigh in.
opened 12:23PM - 15 Jul 20 UTC
E-hard
S-unactionable
A lot of function-like procedural macros might have syntax alien to Rust (`html!… ` Yew macro comes to mind). Highlighing based on expansion is not always reliable as a lot of tokens might not end up in the final code.
So instead of trying to handle every case, I believe there should be an official way to extend rust-analyzer with custom language services and syntax highlights, this would allow library authors to offer better DX for their custom macros.
### Proposal
#### A TextMate scope for macros (VSCode)
A custom scope like `meta.macro-function.rust` would allow syntax highlighting coming from somewhere else, since scope names cannot be dynamic, the scope should span the entire macro invocation (`my_macro!(...)`), this way rules can be matched based on the macro's name.
#### Registering external macro LSPs
External LSPs could be registered for macros and rust-analyzer would forward requests to them. In VSCode, this could be done via the extension API based on [this stack overflow answer](https://stackoverflow.com/a/50068416/1619594).
This way rust-analyzer can decide not to forward known macros it can handle, and there are no multiple LSPs processing the same document simultaneously, potentially clashing with each other.
Macros would be processed in the following order:
- Known macros (e.g. `println`)
- Registered LSP if found by the macro path
- Best-effort based on expansion
### Unresolved questions
- [ ] I only considered VSCode, as I don't use or know the internals of other editors rust-analyzer supports.
- [ ] Macros can be imported by a different name. Rust-analyzer could find out its original name/path, but this wouldn't work for syntax highlights.
- [ ] Scrap the TextMate highlight support, and allow macro LSPs to provide semantic tokens.
- [ ] This feature would further encourage people to write macros with custom alien syntax, but it's already happening anyway.
It would indeed be interesting, but I'm wondering what it'll do to performances.