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 https://github.com/rust-lang/rust/issues/52576
Fixes https://github.com/rust-lang/rust/issues/52512
Fixes https://github.com/rust-lang/rust/issues/51277
cc https://github.com/rust-lang/rust/issues/52269
rustc_resolve: record single-segment extern crate import resolutions.
Fixes#52489 by recording special-cased single-segment imports for later (e.g. stability) checks.
cc @alexcrichton @Mark-Simulacrum @petrochenkov
Does this need to be backported?
[NLL] Fix some things for bootstrap
Some changes that are required when bootstrapping rustc with NLL enabled.
* Remove a bunch of unused `mut`s that aren't needed, but the existing lint doesn't catch.
* Rewrite a function call to satisfy NLL borrowck. Note that the borrow is two-phase, but gets activated immediately by an unsizing coercion.
cc #51823
Don't format!() string literals
Prefer `to_string()` to `format!()` take 2, this time targetting string literals. In some cases (`&format!("...")` -> `"..."`) also removes allocations. Occurences of `format!("")` are changed to `String::new()`.
Attach deprecation lint `proc_macro_derive_resolution_fallback` to a specific node id
So it can be `allow`-ed from inside the derive.
cc https://github.com/rust-lang/rust/pull/51952
This commit stabilizes some of the `proc_macro` language feature as well as a
number of APIs in the `proc_macro` crate as [previously discussed][1]. This
means that on stable Rust you can now define custom procedural macros which
operate as attributes attached to items or `macro_rules!`-like bang-style
invocations. This extends the suite of currently stable procedural macros,
custom derives, with custom attributes and custom bang macros.
Note though that despite the stabilization in this commit procedural macros are
still not usable on stable Rust. To stabilize that we'll need to stabilize at
least part of the `use_extern_macros` feature. Currently you can define a
procedural macro attribute but you can't import it to call it!
A summary of the changes made in this PR (as well as the various consequences)
is:
* The `proc_macro` language and library features are now stable.
* Other APIs not stabilized in the `proc_macro` crate are now named under a
different feature, such as `proc_macro_diagnostic` or `proc_macro_span`.
* A few checks in resolution for `proc_macro` being enabled have switched over
to `use_extern_macros` being enabled. This means that code using
`#![feature(proc_macro)]` today will likely need to move to
`#![feature(use_extern_macros)]`.
It's intended that this PR, once landed, will be followed up with an attempt to
stabilize a small slice of `use_extern_macros` just for procedural macros to
make this feature 100% usable on stable.
[1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252
resolve: Functions introducing procedural macros reserve a slot in the macro namespace as well
Similarly to https://github.com/rust-lang/rust/pull/52234, this gives us symmetry between internal and external views of a crate, but in this case it's always an error to call a procedural macro in the same crate in which it's defined.
Closes https://github.com/rust-lang/rust/issues/52225
This commit adds a lint to the compiler to warn against the `#[macro_use]`
directive as part of the `rust_2018_idioms` lint. This lint is turned off by
default and is only enabled when the `use_extern_macros` feature is also
enabled.
The lint here isn't fully fleshed out as it's just a simple warning rather than
suggestions of how to actually import the macro, but hopefully it's a good base
to start from!
cc #52043
rustc: Search all derives for inert attributes
This commit fixes an apparent mistake in librustc_resolve where when the
`proc_macro` feature is enabled (or `rust_2018_preview`) the resolution of
custom attributes for custom derive was tweaked. Previously when an attribute
failed to resolve it was attempted to locate if there is a custom derive also in
scope which declares the attribute, but only the first custom derive directive
was search.
Instead this commit fixes the loop to search all custom derive invocations
looking for any which register the attribute in question.
Closes#52219
hygiene: Decouple transparencies from expansion IDs
And remove fallback to parent modules during resolution of names in scope.
This is a breaking change for users of unstable macros 2.0 (both procedural and declarative), code like this:
```rust
#![feature(decl_macro)]
macro m($S: ident) {
struct $S;
mod m {
type A = $S;
}
}
fn main() {
m!(S);
}
```
or equivalent
```rust
#![feature(decl_macro)]
macro m($S: ident) {
mod m {
type A = $S;
}
}
fn main() {
struct S;
m!(S);
}
```
stops working due to module boundaries being properly enforced.
For proc macro derives this is still reported as a compatibility warning to give `actix_derive`, `diesel_derives` and `palette_derive` time to fix their issues.
Fixes https://github.com/rust-lang/rust/issues/50504 in accordance with [this comment](https://github.com/rust-lang/rust/issues/50504#issuecomment-399764767).
This commit fixes an apparent mistake in librustc_resolve where when the
`proc_macro` feature is enabled (or `rust_2018_preview`) the resolution of
custom attributes for custom derive was tweaked. Previously when an attribute
failed to resolve it was attempted to locate if there is a custom derive also in
scope which declares the attribute, but only the first custom derive directive
was search.
Instead this commit fixes the loop to search all custom derive invocations
looking for any which register the attribute in question.
Closes#52219
