@Vadim Petrochenkov I am trying to understand what are the goal of
parent_module_of_macro_def. What are the goals of those functions? Are they tracked for incr. comp. in any way? Should they be?
Are they tracked for incr. comp. in any way?
Should they be?
Well, probably yes.
If values returned by these function change, then results of type-based name resolution may change as well.
I am trying to understand what are the goal of expansion_that_defined and parent_module_of_macro_def.
The main idea is that name resolution performed during type checking (things like
object.method) is performed hygienically with macros 2.0, in the same way as name resolution performed during the main resolution pass that is run earlier.
For that we need to keep some hygiene data around, e.g. for resolving a name using def-site hygiene we need to know location of a macro that produced that name (to try resolving the name at that location).
That's the idea, but the current implementation may be somewhat sketchy and I don't remember its details right now.
I think the regression in #85153 comes from an over-pessimistic invalidation of dependents of those two functions. Since they are directly called from typeck, compile_codegen_unit... those expensive queries had to be recomputed every time.
I'd like to querify them. However,
ExpnId cannot be recovered from a fingerprint, so the query cannot be marked green if it has not been invoked manually.
Since this is an existing bug, we could let it fly, but this makes me slightly uncomfortable.
The (somewhat) good news is that these functions only have effect on unstable kinds of macros, so all possible bugs are limited to nightly.
Last updated: Oct 21 2021 at 21:46 UTC