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
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".
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
Enforce the shadowing restrictions from RFC 1560 for today's macros
This PR enforces a weakened version of the shadowing restrictions from RFC 1560. More specifically,
- If a macro expansion contains a `macro_rules!` macro definition that is used outside of the expansion, the defined macro may not shadow an existing macro.
- If a macro expansion contains a `#[macro_use] extern crate` macro import that is used outside of the expansion, the imported macro may not shadow an existing macro.
This is a [breaking-change]. For example,
```rust
macro_rules! m { () => {} }
macro_rules! n { () => {
macro_rules! m { () => {} } //< This shadows an existing macro.
m!(); //< This is inside the expansion that generated `m`'s definition, so it is OK.
} }
n!();
m!(); //< This use of `m` is outside the expansion, so it causes the shadowing to be an error.
```
r? @nrc
Assign node ids during macro expansion
After this PR,
- The `ExtCtxt` can access `resolve`'s `Resolver` through the trait object `ext::base::Resolver`.
- The `Resolver` trait object can load macros and replaces today's `MacroLoader` trait object.
- The macro expander uses the `Resolver` trait object to resolve macro invocations.
- The macro expander assigns node ids and builds the `Resolver`'s `macros_at_scope` map.
- This is groundwork for merging import resolution and expansion.
- Performance of expansion together with node id assignment improves by ~5%.
**EDIT:** Since Github is reordering the commits, here is `git log`:
- b54e1e3997: Differentiate between monotonic and non-monotonic expansion and only assign node ids during monotonic expansion.
- 78c0039878: Expand generated test harnesses and macro registries.
- f3c2dca353: Remove scope placeholders from the crate root.
- c86c8d41a2: Perform node id assignment and `macros_at_scope` construction during the `InvocationCollector` and `PlaceholderExpander` folds.
- 72a636975f: Move macro resolution into `librustc_resolve`.
- 20b43b2323: Rewrite the unit tests in `ext/expand.rs` as a `compile-fail` test.
- a9821e1658: Refactor `ExtCtxt` to use a `Resolver` instead of a `MacroLoader`.
- 60440b226d: Refactor `noop_fold_stmt_kind` out of `noop_fold_stmt`.
- 50f94f6c95: Avoid needless reexpansions.
r? @nrc
The span labels for associated types and consts were hardcoded to `Foo`
rather than substituting the name of the trait.
This also normalizes the wording for associated methods', traits', and
consts' span labels.
Fixes#36428.
Change E0259 to the new error format
Fixes#35514 as part of #35233.
Sorry about creating a new PR I was having a lot of troubles squashing the commit because I didn't properly branch the new feature.
r? @GuillaumeGomez
Batch up libsyntax breaking changes
Batch of the following syntax-[breaking-change] changes:
- #35591: Add a field `span: Span` to `ast::Generics`.
- #35618: Remove variant `Mod` of `ast::PathListItemKind` and refactor the remaining variant `ast::PathListKind::Ident` to a struct `ast::PathListKind_`.
- #35480: Change uses of `Constness` in the AST to `Spanned<Constness>`.
- c.f. `MethodSig`, `ItemKind`
- #35728: Refactor `cx.pat_enum()` into `cx.pat_tuple_struct()` and `cx.pat_path()`.
- #35850: Generalize the elements of lists in attributes from `MetaItem` to a new type `NestedMetaItem` that can represent a `MetaItem` or a literal.
- #35917: Remove traits `AttrMetaMethods`, `AttributeMethods`, and `AttrNestedMetaItemMethods`.
- Besides removing imports of these traits, this won't cause fallout.
- Add a variant `Union` to `ItemKind` to future proof for `union` (c.f. #36016).
- Remove inherent methods `attrs` and `fold_attrs` of `Annotatable`.
- Use methods `attrs` and `map_attrs` of `HasAttrs` instead.
r? @Manishearth
* A step towards #34902
* More stable error messages in some places related to crate loading
* Possible slight performance improvements since all `HashMap`s
replaced had small keys where `FnvHashMap` should be faster
(although I didn't measure)
