Refactor our eager macro infra #15371
Labels
A-macro
macro expansion
C-Architecture
Big architectural things which we need to figure up-front (or suggestions for rewrites :0) )
C-enhancement
Category: enhancement
The current approach has some drawbacks, one being it is a complete mess :) Though I think a proper refactor needs to also look at our macro resolution loop in general unfortunately, or maybe the design of rust macro resolution loop is just incompatible with a nice IDE story.
The way things work right now is that we effectively take input token trees of eager macros and reparse them as comma separated expressions and set that as the expansion of a fake input macro call for the actual eager macro call. We then expand all macros we find in that expansion manually and replacing the calls with the actual expansion and finally we write this expansion into a specific eager expansion field of a macro call loc whereas that macro call loc represents the actual macro invocation. This manual editing of the syntax tree is a mess that we should not need to do, but it is currently somewhat necessary as we can't defer resolving the macro calls to the standard expansion query as that would end in cycles. (In the rust compiler eager macro expansions basically just tap back into the macro resolution loop transparently, we don't have this luxury)
This current approach also has the problem that we are unable to resolve the eagerly expanded macros in the IDE layer as they effectively do not exist in any records (fun fact, a similar problem will exist for the proc-macro equivalent TokenStream::expand_epr, though there we can't really fix anything up from our side, rust-lang/rust#90765).
The current eager implementation lives here https://github.com/rust-lang/rust-analyzer/blob/master/crates/hir-expand/src/eager.rs
The text was updated successfully, but these errors were encountered: