Make mtwt resolution part of the HIR lowering

[nrc]

Currently we do the resolution step of mtwt lazily and on demand in name resolution and (unfortunately) elsewhere. That means we have to keep the (big) tables around longer than is nice and means we are open to hygiene bugs where people forget to do mtwt resolution.

A better solution is to eagerly do mtwt resolution as part of the HIR lowering step. This also means no more Idents in the HIR, only Names, which is a plus.

Happy to mentor this, it's probably better as a second or third bug than a first though since its not super easy.

[petrochenkov]

I tried it as an alternative to #29748, I agree, it would be much nicer and would kill such hygiene bugs in their root.
Unfortunately, mtwt::resolve can't be applied to everything during lowering to HIR, because of ambiguity between variants/constants and bindings in patterns (and in paths too). For a specific identifier it should be determined first if it is a new binding (then it needs to be renamed) or not (then it should not be renamed), i.e. this step has to be performed after or during name resolution.

Maybe things can be restructured somehow, so that HIR could be modified once more after resolution?

[nrc]

Could you give an example of a not-new binding that should not be renamed? My understanding was that applying the mtwt algorithm should handle all of that, and mtwt::resolve would always work (as long as it's a variable, not for other objects.

[petrochenkov]

match opt {
    None => {}
    a => {}
}

None is parsed as PatIdent and if all PatIdents are renamed during lowering, then we get something like

match opt {
    None1 => {}
    a1 => {}
}

when we start name resolution, so None1 is not identified as Option::None during resolution and therefore interpreted as a new binding.

[nrc]

Urgh. I'll have to think about that...

[nrc]

Having thought about this, I agree this is a show-stopper, also the world is a cold and awful place.

I think the 'right' thing to do here is to merge the HIR lowering with name resolution so there are no un-resolved names in the HIR (modulo associated types), that needs thought to see if it will work, I guess.