-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
resolve: Implement prelude search for macro paths, implement tool attributes #52841
Conversation
r? @cramertj (rust_highfive has picked a reviewer for you, use r? to override) |
r? @alexcrichton |
Err(Determinacy::Determined) | ||
} | ||
} | ||
WhereToResolve::StdLibPrelude => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FIXME: account for no_implicit_prelude
.
Done.
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Looks great to me, thanks for the detailed comments! It looks like tool attributes like |
@bors r=alexcrichton |
📌 Commit dd93535e028ece7f01491fd25c8369d375026f69 has been approved by |
@bors p=1 edition critical |
🔒 Merge conflict This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again. How do I rebase?Assuming
You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial. Please avoid the "Resolve conflicts" button on GitHub. It uses Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Error message
|
This is also blocking edition crater runs. |
resolve/expansion: Implement tool attributes
@bors r=alexcrichton |
📌 Commit c3e5421 has been approved by |
⌛ Testing commit c3e5421 with merge e53bca8baf30e0686c3b2b82af3db0be0d592a64... |
@bors r=alexcrichton |
📌 Commit c3e5421 has been approved by |
@bors p=1 |
@bors: rollup- |
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
☀️ Test successful - status-appveyor, status-travis |
This breaks Servo in a weird way. I'm unable to reproduce this out of tree https://travis-ci.org/servo/servo-with-rust-nightly/jobs/411851355
any idea what's going on? seems like a regression |
cc @pietroalbini might want to be careful about that regression before cutting a beta ^^ |
I'll look what happens. |
@Manishearth In this case macro expanded name (macro_rules macro Minimized reproduction: macro_rules! my_include {() => {
#[macro_use] extern crate log;
}}
my_include!();
fn main() {
warn!("");
} In this case, since breakage affects stable channel, built-in attributes can be somehow special-cased to avoid the error, or perhaps some more general solution can be found, but I'd prefer to see crater results before proceeding with a fix. |
Since #53072 doesn't include this PR, we need a separate crater run for it. |
Queued a crater run for this PR (check only) here: #53089 |
Good news! This PR improved compile speed on a few benchmarks, the best by 3.7%: |
Stabilize a few secondary macro features - `tool_attributes` - closes rust-lang#44690 - `proc_macro_path_invoc` - this feature was created due to issues with tool attributes (rust-lang#51277), those issues are now fixed (rust-lang#52841) - partially `proc_macro_gen` - this feature was created due to issue rust-lang#50504, the issue is now fixed (rust-lang#51952), so proc macros can generate modules. They still can't generate `macro_rules` items though due to unclear hygiene interactions.
Stabilize a few secondary macro features - `tool_attributes` - closes #44690 - `proc_macro_path_invoc` - this feature was created due to issues with tool attributes (#51277), those issues are now fixed (#52841) - partially `proc_macro_gen` - this feature was created due to issue #50504, the issue is now fixed (#51952), so proc macros can generate modules. They still can't generate `macro_rules` items though due to unclear hygiene interactions.
Resolves rustc error E0659 in the base.rs example caused by [rust-lang/rust](https://github.com/rust-lang/rust) pull request [#52841](rust-lang/rust#52841) "resolve: Implement prelude search for macro paths, implement tool attributes."
Resolves nightly rustc error E0659 in the base.rs example caused by [rust-lang/rust](https://github.com/rust-lang/rust) pull request [#52841](rust-lang/rust#52841) "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
infoo::mac!()
orfoo!()
), 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 infn resolve_lexical_macro_path_segment
for more details."Tool prelude" currently contains two "tool modules"
rustfmt
andclippy
, and is searched immediately after extern prelude.This makes the possible 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 fortool_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