Stream: t-compiler/wg-rls-2.0

Topic: Expanding macros in `world_symbols`


Timo Freiberg (Apr 09 2020 at 15:20, on Zulip):

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?):

  1. 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.

  2. sema.expand returns a SyntaxNode, but to recursively call source_file_to_file_symbols I need a SourceFile
    -> or actually, I just need something to call .syntax() on, so an AstNode
    -> or actually, I can just change the signature of source_file_to_file_symbols to take the SyntaxNode that .syntax() returns... :face_palm:

Florian Diebold (Apr 09 2020 at 15:23, on Zulip):

I wonder if we shouldn't start building the index from HIR instead

Timo Freiberg (Apr 09 2020 at 15:23, on Zulip):

Would that change the approach completely?

Florian Diebold (Apr 09 2020 at 15:23, on Zulip):

yes, pretty much

Timo Freiberg (Apr 09 2020 at 15:26, on Zulip):

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?

Florian Diebold (Apr 09 2020 at 15:26, on Zulip):

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

Florian Diebold (Apr 09 2020 at 15:26, on Zulip):

yes

Florian Diebold (Apr 09 2020 at 15:27, on Zulip):

not sure what @matklad thinks though, I haven't really dealt with the symbol index so far

matklad (Apr 09 2020 at 15:27, on Zulip):

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:

matklad (Apr 09 2020 at 15:27, on Zulip):

Instead of completely forgetting the cfged-out items, we should still collect them, but in a "disabled" state

Florian Diebold (Apr 09 2020 at 15:28, on Zulip):

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

matklad (Apr 09 2020 at 15:28, on Zulip):

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

Timo Freiberg (Apr 09 2020 at 15:30, on Zulip):

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

matklad (Apr 09 2020 at 15:31, on Zulip):

Agree that bolting on macro-expansion for the current crate on top of our index is not that much of work

matklad (Apr 09 2020 at 15:31, on Zulip):

IIRC, I did that at one point, in the very first implementation of macro expansion

Timo Freiberg (Apr 09 2020 at 17:48, on Zulip):

so, do you think it's worth it to work on the current index? or should that effort rather be focused on redesigning it?

Timo Freiberg (Apr 12 2020 at 18:16, on Zulip):

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?

Last update: Sep 30 2020 at 16:30UTC