Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
petrochenkov opened this issue Dec 1, 2018 · 0 comments
Labels
A-resolve Area: Name resolution C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@petrochenkov
Copy link
Contributor

petrochenkov commented Dec 1, 2018

"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). <--

@petrochenkov petrochenkov added A-resolve Area: Name resolution C-bug Category: This is a bug. labels Dec 1, 2018
@jonas-schievink jonas-schievink added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Feb 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-resolve Area: Name resolution C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants