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

Macro path resolution ignores preludes #52512

Closed
petrochenkov opened this issue Jul 18, 2018 · 1 comment · Fixed by #52841
Closed

Macro path resolution ignores preludes #52512

petrochenkov opened this issue Jul 18, 2018 · 1 comment · Fixed by #52841
Assignees
Labels
A-macros-1.2 Area: Declarative macros 1.2 A-macros-2.0 Area: Declarative macros 2.0 (#39412) A-resolve Area: Name/path resolution done by `rustc_resolve` specifically

Comments

@petrochenkov
Copy link
Contributor

petrochenkov commented Jul 18, 2018

All kinds of them - extern prelude, standard library prelude, language prelude, except for the macro prelude of course (which contains of builtin macros and macros from #[macro_use] extern crate).

#![feature(extern_prelude, use_extern_macros)]
#![allow(unused)]

mod m {
    fn f() {
        std::mem::drop(0); // OK, extern prelude
        Result::Ok::<u8, u8>(0); // OK, standard library prelude
        u8::clone(&0); // OK, language prelude
        
        std::panic!(); // ERROR failed to resolve. Use of undeclared type or module `std`
        Result::Ok!(); //  ERROR failed to resolve. Use of undeclared type or module `Result`
        u8::clone!(); // ERROR failed to resolve. Use of undeclared type or module `u8`
    }
}

fn main() {}
@petrochenkov
Copy link
Contributor Author

petrochenkov commented Jul 18, 2018

The fix is potentially a minor breaking change due to certain kinds of shadowing being prohibited in macro paths:

#![feature(decl_macro)]
#![allow(unused)]

mod m {
    fn f() {
        macro_rules! mac { () => {
            mod std {
                pub macro panic() {}
            }
        }}
        
        std::panic!(); // should be an ERROR: ambiguous prelude vs macro-expanded module
                            // not an error now due to prelude being ignored
        
        mac!();
    }
}

fn main() {}

I think we can leave this to post-1.2 though.

@petrochenkov petrochenkov added A-resolve Area: Name/path resolution done by `rustc_resolve` specifically A-macros-2.0 Area: Declarative macros 2.0 (#39412) A-macros-1.2 Area: Declarative macros 1.2 labels Jul 18, 2018
@petrochenkov petrochenkov self-assigned this Jul 21, 2018
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Aug 1, 2018
resolve: Implement prelude search for macro paths, implement tool attributes

When identifier is macro path is resolved in scopes (i.e. the first path segment - `foo` in `foo::mac!()` or `foo!()`), scopes are searched in the same order as for non-macro paths - items in modules, extern prelude, tool prelude (see later), standard library prelude, language prelude, but with some extra shadowing restrictions (names from globs and macro expansions cannot shadow names from outer scopes). See the comment in `fn resolve_lexical_macro_path_segment` for more details.

"Tool prelude" currently contains two "tool modules" `rustfmt` and `clippy`, and is searched immediately after extern prelude.
This makes the [possible long-term solution](https://github.com/rust-lang/rfcs/blob/master/text/2103-tool-attributes.md#long-term-solution) for tool attributes exactly equivalent to the existing extern prelude scheme, except that `--extern=my_crate` making crate names available in scope is replaced with something like `--tool=my_tool` making tool names available in scope.

The `tool_attributes` feature is still unstable and `#![feature(tool_attributes)]` now implicitly enables `#![feature(use_extern_macros)]`. `use_extern_macros` is a prerequisite for `tool_attributes`, so their stabilization will happen in the same order.
If `use_extern_macros` is not enabled, then tool attributes are treated as custom attributes (this is temporary, anyway).

Fixes rust-lang#52576
Fixes rust-lang#52512
Fixes rust-lang#51277
cc rust-lang#52269
bors added a commit that referenced this issue Aug 2, 2018
resolve: Implement prelude search for macro paths, implement tool attributes

When identifier is macro path is resolved in scopes (i.e. the first path segment - `foo` in `foo::mac!()` or `foo!()`), scopes are searched in the same order as for non-macro paths - items in modules, extern prelude, tool prelude (see later), standard library prelude, language prelude, but with some extra shadowing restrictions (names from globs and macro expansions cannot shadow names from outer scopes). See the comment in `fn resolve_lexical_macro_path_segment` for more details.

"Tool prelude" currently contains two "tool modules" `rustfmt` and `clippy`, and is searched immediately after extern prelude.
This makes the [possible long-term solution](https://github.com/rust-lang/rfcs/blob/master/text/2103-tool-attributes.md#long-term-solution) for tool attributes exactly equivalent to the existing extern prelude scheme, except that `--extern=my_crate` making crate names available in scope is replaced with something like `--tool=my_tool` making tool names available in scope.

The `tool_attributes` feature is still unstable and `#![feature(tool_attributes)]` now implicitly enables `#![feature(use_extern_macros)]`. `use_extern_macros` is a prerequisite for `tool_attributes`, so their stabilization will happen in the same order.
If `use_extern_macros` is not enabled, then tool attributes are treated as custom attributes (this is temporary, anyway).

Fixes #52576
Fixes #52512
Fixes #51277
cc #52269
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros-1.2 Area: Declarative macros 1.2 A-macros-2.0 Area: Declarative macros 2.0 (#39412) A-resolve Area: Name/path resolution done by `rustc_resolve` specifically
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant