@matklad I was thinking of trying to tackle at least partial analysis within macro_rules! bodies. My thought was that we could guarantee resolution of items like
$crate and the paths that follow. Is there any existing issue based on that, or do you have any thoughts on whether we should approach something like that right now?
I think the best approach would be to do it like how I proposed in https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/macro_rules.20highlighting
But there's no issue created for this yet.
I know that topic talks about analyzing content inside
macro! but it is relevant to also analyzing content inside
I looked into it this morning. The biggest issue is that the body of a macro_rules macro is just a token tree, and there's currently no analysis done if the macro itself isn't called. @matklad could we sync at some point to go over a best path forward here? I have a couple ideas, but not sure which is the best approach:
macro_rulesto the ungrammar
macro_rulesthat "forwards" the kinds of the metavars into the AST
NameRef's external to the macro if they were part of a
I don't think it makes sense to do any kind of "fancy" analysis of macro bodies any time soon
This is a deeply heurisitc thing, and it's not like we got the basic stuff working
What can, and should be done though, is supporting goto definition and compleiton for meta vars
$foo should bring one to
I am not sure how to best achieve this, as macro machinery fundametally works with token trees, and not the syntax trees
I think the right approach here is just a huge wad of code in
ide which uses
TokenID to switch bridge the two representations
Could we at least have the ungrammar account for this within macro rules? https://doc.rust-lang.org/reference/macros-by-example.html
I noticed it's not in the official grammar (the one being produced by wg-grammar), but only in the reference linked above.
I don't think this should be handle by ungrammar -- macros are token trees
ide would be the area to handle
macro_rules in a special way?
IDE would call into mbe to make sense of macro rules invocations
should also stress our IR-mapping infrastructure (not that we have any :D ), as mbe are essentially are a separate IR
I did not even realize
mbe existed. Ok I'll review this for the time being. Thanks for following up!
Can someone please tag this issue as macro? https://github.com/rust-analyzer/rust-analyzer/issues/5972