I'm slowly working on https://github.com/rust-analyzer/rust-analyzer/issues/3851 on the side and I don't want to spam the Github issue anymore, so I'm writing my questions down here.
Issues I was stuck on for a while but then solved (maybe someone will find those interesting?):
A freshly created
Semantics in the leaf call failed to expand the macro because its cache was empty.
-> then I noticed that the parent function
file_symbols actually parses the file via
db.parse. Creating a
Semantics at the start of the function and calling
sema.parse instead filled the cache. Passing that
sema instance down worked.
sema.expand returns a
SyntaxNode, but to recursively call
source_file_to_file_symbols I need a
-> or actually, I just need something to call
.syntax() on, so an
-> or actually, I can just change the signature of
source_file_to_file_symbols to take the
.syntax() returns... :face_palm:
I wonder if we shouldn't start building the index from HIR instead
Would that change the approach completely?
yes, pretty much
Hm, I'm interested yet I'm not even sure how to express my questions :sweat_smile:
I guess the current approach is AST-based?
I think it's something that we do want to do at some point, and it might not be worth the effort to try to adapt the current approach to expand macros
not sure what @matklad thinks though, I haven't really dealt with the symbol index so far
Yeah, I think we are roughtly at the position where hir-based index is worthwhile.
I think the only pre-requesite we need to do is this:
Instead of completely forgetting the cfged-out items, we should still collect them, but in a "disabled" state
so then to build the index you'd walk through all the modules pretty similarly to how we do it in analysis-stats, I guess
Uhm..... Now that I think about it, it might be the case that what we want is an index based on the item-tree IR
For what it's worth, I think a not-very-pretty version of including macro-expanded code in the index is not far off, but I'm very new to the codebase so there are lots of unknown unknowns
Agree that bolting on macro-expansion for the current crate on top of our index is not that much of work
IIRC, I did that at one point, in the very first implementation of macro expansion
so, do you think it's worth it to work on the current index? or should that effort rather be focused on redesigning it?
I continued trying to bolt on macro-expansion for a bit until I got stuck remapping the text range. My motivation to continue is not very high, partly because I feel like it might be better to work on a hir-based index. Is there a ticket for that?