I'm looking into how to fix https://github.com/rust-analyzer/rust-analyzer/issues/9142, aaand this looks potentially quite difficult, since any syntactical item might actually be a macro call. There doesn't happen to be a convenient place to check for this and have everything magically work, right?
Yeah, I think this is fundamentally tricky.....
Basically, the problem with this is that
source2def(src).src == src equality does not hold with attributes
That is, we start with annotated fn node, but should get a def whose source is actually in an expanded file
well in principle, there just is no def for the original fn ast node, is there?
it's like calling
to_def on a macro call
so I guess that the IDE functionality should first be descending into the macro calls, but it doesn't because it's only looking for
MacroCall nodes? :thinking:
there just is no def for the original fn ast node, is there?
unless the node gets passed through completely by the attribute of course, then it might be arguable that there is... but I'm not sure whether it would be necessary or helpful to do that
descend_into_macros, we need to not just look for
MacroCalls, but also any ancestors annotated with proc macro attributes?
yeah I played around with
descend_into_macros the other day, that might get us some of the way there already
descend_into_macros to work with attribute macro, and it seems to work when printing the original and remapped token. I've also changed
syntax_highlighting.rs to account for attribute macros and descend into them, but somehow all identifiers in the invocation stay unresolved. Any idea what might cause this? Do we have any way to debug the token mapping?
This is now largely fixed, but some way to debug
TokenMap operations would still be nice