Known deviations of macro paths and 2018 import paths from the "uniform path" model #56413

"Uniform path" model for macros/imports means that if macro/import path compiles without errors, it's resolved in exactly same way as non-macro/import path.

(Possible differences in resolution of macro/import paths and other paths are caused by the fact that macro/import paths are resolved early, when module structure of the crate is still in flux.)

There are two known deviations from this model.
Import/macro resolution never sees local variables (let x) and generic parameters (T in fn f<T>() { ... }) - we don't have necessary infrastructure to do that during early resolution right now.

There's still some future-proofing in place turning imports referring to local variables and generic parameters into errors - 22a13ef, but that future proofing has two holes.

First, macro paths are not future-proofed:

mod T { // T1
    pub macro mac() {}
}
fn f<T>() { // T2
    T::mac!(); // Should be an error because T2 shadows T1, but it's not.
}

To fix this, expanded macros need to leave better traces for late resolution, so that positions of expanded macros relative to generic parameters are known.

UPDATE: Fixed in #56759 --> Second, future-proofing for non-renamed single-segment imports referring to generic parameters doesn't work due to an implementation issue:

fn self_import<T>() {
    use T; // FIXME Should be an error, but future-proofing fails due to `use T` being "self-confirming"
}

To fix this we need to stop treating the import use T; as "self-confirming" during future-proofing resolution (similarly to how it's done for single-segment imports in #56392). <--