Add support for use Trait::func

[Veykril]

rust-lang/rfcs#3591 is likely to be introduced to the language, which will require some changes to our early name resolution, notably this change ties in trait assoc items into early name resolution so our corresponding DefMap query will have to collect and expand macros in trait assoc item position, replacing the current trait_data query. This will unfortunately slow down def map creation and also invalidate it when trait assoc item signatures are changed but that's just the nature of moving things into early nameres. OTOH this does get rid of one of the more frequent queries which might slightly reduce memory usage/or improve perf in other ways.

Note this hasn't been accepted yet so there is little reason to implement that right now.

[ChayimFriedman2]

I don't see why this forces us to introduce trait data into DefMap. Since macros cannot be trait members, trait members cannot affect the fixpoint algorithm of name resolution. Therefore, we can stop as soon as we resolved the before-last segment to a trait, and maintain a list of "probably/should be trait assoc items" of TraitId and Names. We'll probably need to have a query to resolve them anyway (for diagnostics etc.), but that will be a very lightweight query that will not recompute the DefMap.

[Veykril]

I think my reasoning here was that we need to call trait_data to resolve a segment to the relevant AssocItemId (which means post expansion since you can have macro calls as associated items), this means we need a fully constructed def map here (to do macro expansion), and so if it turns out that def map is the one we are currently computing we hit a cycle def_map -> trait_data -> same def_map.

Happy to be proven wrong though if my thinking is incorrect / or the problem can be avoided somehow!

[ChayimFriedman2]

That would be a problem for your approach, but not mine, no? My entire point is that we don't call trait_data() instead the def map.

[Veykril]

But then how will you access the associated items post expansion? The following is valid rust.

macro_rules! f_maker {
    () => { fn f() {} }
}

trait T {
    f_maker!();
}

[Veykril]

Therefore, we can stop as soon as we resolved the before-last segment to a trait, and maintain a list of "probably/should be trait assoc items" of TraitId and Names.

Ah I guess this part is the workaround for it (deferring the full resolution to the end?) if I understood you correctly. That feels rather hacky to me though

[ChayimFriedman2]

But then how will you access the associated items post expansion? The following is valid rust.

DefMap will expand the macro (as it expands all macros), but it won't (fully) resolve the import. Yes, this is a hack, but if the other approach proves to be to expensive we can try that.