Stabilize `..` in tuple (struct) patterns
I'd like to nominate `..` in tuple and tuple struct patterns for stabilization.
This feature is a relatively small extension to existing stable functionality and doesn't have known blockers.
The feature first appeared in Rust 1.10 6 months ago.
An example of use: https://github.com/rust-lang/rust/pull/36203
Closes https://github.com/rust-lang/rust/issues/33627
r? @nikomatsakis
macros: improve shadowing checks
This PR improves macro-expanded shadowing checks to work with out-of-(pre)order expansion.
Out-of-order expansion became possible in #37084, so this technically a [breaking-change] for nightly.
The regression test from this PR is an example of code that would break.
r? @nrc
Add E0532 error explanation
This resolves one of the error list in https://github.com/rust-lang/rust/issues/35347 - just because I stumbled over it today.
I assumed the error code should be removed from `register_diagnostics!` because it's now defined above.
Since that is my first code contribution, please check that all is in order. It would be helpful to know how to run the test for the `compile_fail,E0532` part. I did `make check-stage1-cfail NO_REBUILD=1` but that doesn't test the inlined example.
r? @GuillaumeGomez
Add semicolon to "Maybe a missing `extern crate foo`" message
I had it a couple of times that I was missing the "extern crate" line
after I introduced a new dependency. So I copied the text from the
message and inserted it into the beginning of my code, only to find the
compiler complaining that I was missing the semicolon. (I forgot to add
it after the text that I had pasted.)
There's a similar message which does include the semicolon, namely
"help: you can import it into scope: `use foo::Bar;`". I think the two
messages should be consistent, so this change adds it for "extern
crate".
Diagnostics for struct path resolution errors in resolve and typeck are unified.
Self type is treated as a type alias in few places (not reachable yet).
Unsafe cell is seen in constants even through type aliases.
All checks for struct paths in typeck work on type level.
I had it a couple of times that I was missing the "extern crate" line
after I introduced a new dependency. So I copied the text from the
message and inserted it into the beginning of my code, only to find the
compiler complaining that I was missing the semicolon. (I forgot to add
it after the text that I had pasted.)
There's a similar message which does include the semicolon, namely
"help: you can import it into scope: `use foo::Bar;`". I think the two
messages should be consistent, so this change adds it for "extern
crate".
Add identifier to unused import warnings
Fix#37376.
For some reason, though, I'm getting warnings with messages like "76:9: 76:16: unused import: `self::g`" instead of "unused import: `self::g`". @pnkfelix Any ideas what might be causing this?
macros: Future proof `#[no_link]`
This PR future proofs `#[no_link]` for macro modularization (cc #35896).
First, we resolve all `#[no_link] extern crate`s. `#[no_link]` crates without `#[macro_use]` or `#[macro_reexport]` are not resolved today, this is a [breaking-change]. For example,
```rust
```
Any breakage can be fixed by simply removing the `#[no_link] extern crate`.
Second, `#[no_link] extern crate`s will define an empty module in type namespace to eventually allow importing the crate's macros with `use`. This is a [breaking-change], for example:
```rust
mod syntax {} //< This becomes a duplicate error.
```
r? @nrc
macros 1.1: future proofing and cleanup
This PR
- uses the macro namespace for custom derives (instead of a dedicated custom derive namespace),
- relaxes the shadowing rules for `#[macro_use]`-imported custom derives to match the shadowing rules for ordinary `#[macro_use]`-imported macros, and
- treats custom derive `extern crate`s like empty modules so that we can eventually allow, for example, `extern crate serde_derive; use serde_derive::Serialize;` backwards compatibly.
r? @alexcrichton
Changed error message E0408 to new format
Followed your text and was able to change the ouput to the new format.
I did not encounter any broken test therefore this is a really small commit.
Thanks for letting me hack on the compiler :)
r? @jonathandturner
macros: clean up scopes of expanded `#[macro_use]` imports
This PR changes the scope of macro-expanded `#[macro_use]` imports to match that of unexpanded `#[macro_use]` imports. For example, this would be allowed:
```rust
example!();
macro_rules! m { () => { #[macro_use(example)] extern crate example_crate; } }
m!();
```
This PR also enforces the full shadowing restrictions from RFC 1560 on `#[macro_use]` imports (currently, we only enforce the weakened restrictions from #36767).
This is a [breaking-change], but I believe it is highly unlikely to cause breakage in practice.
r? @nrc
Turn compatibility lint `match_of_unit_variant_via_paren_dotdot` into a hard error
The lint was introduced 10 months ago and made deny-by-default 7 months ago.
In case someone is still using it, https://github.com/rust-lang/rust/pull/36868 contains a stable replacement.
r? @nikomatsakis
rustc: Rename rustc_macro to proc_macro
This commit blanket renames the `rustc_macro` infrastructure to `proc_macro`,
which reflects the general consensus of #35900. A follow up PR to Cargo will be
required to purge the `rustc-macro` name as well.
This commit blanket renames the `rustc_macro` infrastructure to `proc_macro`,
which reflects the general consensus of #35900. A follow up PR to Cargo will be
required to purge the `rustc-macro` name as well.
