I would like to talk about macros and compiler plugins in the context of IDEs. It’s something I’ve been thinking about recently and I’d like to share a braindump.
I’m working on IntelliJ Rust. As most other IntelliJ IDEA based IDEs, it is designed to be able to fully understand the semantics of Rust code without consulting the compiler/racer/RLS. That is, we are going to implement lexing, parsing, name resolution and type inference.
A major road block for this approach to IDEs are macros and compiler plugins. We are nowhere near handling macros at the moment, but we’ll have to do something with them eventually
While macros by example are hard, but doable, a proper handling of compiler plugins seems impossible. So I am wondering how the effects of a compiler plugin can be understood without the compiler itself.
It’s interesting that code generation tool (which literally dumps source code into some directory which is then fed to the compiler) would work with IDE out of the box. What about designing compiler plugins in such a way that the result of their work is representable as a Rust source code? I guess this may have some nasty interaction with hygiene and mir level plugins?
It’s also interesting that “custom derive” plugins should not be a problem for the IDE, because you know the effect of a plugin (trait X is implemented for type Y). So another approach would be to augment plugins with some kind of metadata about their effects.
Another tool which may prefer code generation to arbitrary plugins is a debugger. If you are debugging an error which manifests itself amid the generated code, what source line should you see in the debugger?