However, I've found that any code generated by procedural macros (impls or even full structs) are never indexed by the IDE for autocompletion. This makes sense -- there is nothing actually there for the IDE to index. I've tried a few IDEs with no success.
I'm curious if anyone has found a workaround for this. Or do we just live with no autocompletion like back in the 80's (when I started on Windows Notepad -- not even Notepad++).
+1, since proc macros can do anything in compile time I suppose the only way for IDE to index its expansion is to run it on the fly... which will slow down the performance anyway. Implementing the feature is therefore really hard, and in my opinion the issue will not be addressed shortly. But at least IntelliJ Rust is not giving false positive error squiggles for these functions, so as a user who is also suffering from the issue I should say perhaps we should just wait?
Technically, I've come up with two ideas on how this can be more efficiently done:
Since now proc macros can only see a limited number of tokens (not the whole AST), perhaps the IDE can somehow cache the expansion result and re-expands only when these tokens change?
Or probably the proc macro itself should help IDE in indexing. For derive macros usually the signatures of functions they implement are fixed, so if there's an interface where proc macros can know whether they are running in IDE instead of real compilation, then they can just expand to code skeletons, with only function signatures and perhaps dummy implementations... that will be enough for indexing and save a lot of time.
So, this does appear to work with the Rust Language Server, though if you change the macro itself, that doesn't get picked up. I know IntelliJ has their own parser, so it might be an IntelliJ problem.
You're welcome! I'm not sure if IntelliJ can be configured to use RLS, or if their DIY Rust support is hard-wired, but if you like their UI it might be worth checking.