syntax: Lower priority of `+` in `impl Trait`/`dyn Trait`
Now you have to write `Fn() -> (impl A + B)` instead of `Fn() -> impl A + B`, this is consistent with priority of `+` in trait objects (`Fn() -> A + B` means `(Fn() -> A) + B`).
To make this viable I changed the syntax to also permit `+` in return types in function declarations
```
fn f() -> dyn A + B { ... } // OK, don't have to write `-> (dyn A + B)`
// This is acceptable, because `dyn A + B` here is an isolated type and
// not part of a larger type with various operator priorities in play
// like `dyn A + B` in `Fn() -> dyn A + B` despite syntax similarities.
```
but you still have to use `-> (dyn A + B)` in function types and function-like trait object types (see this PR's tests for examples).
This can be a breaking change for code using `impl Trait` on nightly. The thing that is most likely to break is `&impl A + B`, it needs to be rewritten as `&(impl A + B)`.
cc https://github.com/rust-lang/rust/issues/34511https://github.com/rust-lang/rust/issues/44662https://github.com/rust-lang/rfcs/pull/438
Correctly format `extern crate` conflict resolution help
Closes#45799. Follow up to @Cldfire's #45820.
If the `extern` statement that will have a suggestion ends on a `;`, synthesize a new span that doesn't include it.
Avoid overlapping spans by only pointing at the arguments that are not
being used in the argument string. Enable libsyntax to have diagnostics
with multiple primary spans by accepting `Into<MultiSpan>` instead of
`Span`.
Properly parse impls for the never type `!`
Recover from missing `for` in `impl Trait for Type`
Prohibit inherent default impls and default impls of auto traits
Change wording in more diagnostics to use "auto traits"
Some minor code cleanups in the parser
No longer parse it.
Remove AutoTrait variant from AST and HIR.
Remove backwards compatibility lint.
Remove coherence checks, they make no sense for the new syntax.
Remove from rustdoc.
`struct` pattern parsing and diagnostic tweaks
- Recover from struct parse error on match and point out missing match
body.
- Point at struct when finding non-identifier while parsing its fields.
- Add label to "expected identifier, found {}" error.
Fix#15980.
Treat #[path] files as mod.rs files
Fixes https://github.com/rust-lang/rust/issues/46936, cc @briansmith, @SergioBenitez, @nikomatsakis.
This (insta-stable) change treats files included via `#[path = "bla.rs"] mod foo;` as though they were `mod.rs` files. Namely, it allows them to include `mod` statements and looks for the child modules in sibling directories, rather than in relative `modname/childmodule.rs` files as happens for non-`mod.rs` files.
This change makes the `non_modrs_mods` feature backwards compatible with the existing usage in https://github.com/briansmith/ring, several versions of which are currently broken in beta. If we decide to merge, this change should be backported to beta.
cc https://github.com/rust-lang/rust/issues/37872
r? @jseyfried
Add help message for incorrect pattern syntax
When I was getting started with rust I often made the mistake of using `||` instead of `|` to match multiple patterns and spent a long time staring at my code wondering what was wrong.
for example:
```
fn main() {
let x = 1;
match x {
1 || 2 => println!("1 or 2"),
_ => println!("Something else"),
}
}
```
If you compile this with current rustc you will see
```
error: expected one of `...`, `..=`, `..`, `=>`, `if`, or `|`, found `||`
--> test.rs:5:11
|
5 | 1 || 2 => println!("1 or 2"),
| -^^ unexpected token
| |
| expected one of `...`, `..=`, `..`, `=>`, `if`, or `|` here
error: aborting due to previous error
```
With my proposed change it will show:
```
error: unexpected token `||` after pattern
--> test.rs:5:11
|
5 | 1 || 2 => println!("1 or 2"),
| ^^
|
= help: did you mean to use `|` to specify multiple patterns instead?
error: aborting due to previous error
```
- Recover from struct parse error on match and point out missing match
body.
- Point at struct when finding non-identifier while parsing its fields.
- Add label to "expected identifier, found {}" error.
Allow lifetimes in macros
This is a resurrection of PR #41927 which was a resurrection of #33135, which is intended to fix#34303.
In short, this allows macros_rules! to use :lifetime as a matcher to match 'lifetimes.
Still to do:
- [x] Feature gate
Do not emit type errors on recovered blocks
When a parse error occurs on a block, the parser will recover and create
a block with the statements collected until that point. Now a flag
stating that a recovery has been performed in this block is propagated
so that the type checker knows that the type of the block (which will be
identified as `()`) shouldn't be checked against the expectation to
reduce the amount of irrelevant diagnostic errors shown to the user.
Fix#44579.
When a parse error occurs on a block, the parser will recover and create
a block with the statements collected until that point. Now a flag
stating that a recovery has been performed in this block is propagated
so that the type checker knows that the type of the block (which will be
identified as `()`) shouldn't be checked against the expectation to
reduce the amount of irrelevant diagnostic errors shown to the user.
Generics refactoring (groundwork for const generics)
These changes were suggested by @eddyb.
After this change, the `Generics` contain one `Vec` of an enum for the generic parameters, rather than two separate `Vec`s for lifetime and type parameters. Type params and const params will need to be in a shared `Vec` to preserve their ordering, and moving lifetimes into the same `Vec` should simplify the code that processes `Generics`.
The Generics now contain one Vec of an enum for the generic parameters,
rather than two separate Vec's for lifetime and type parameters.
Additionally, places that previously used Vec<LifetimeDef> now use
Vec<GenericParam> instead.
syntax: Follow-up to the incorrect qpath recovery PR
cc https://github.com/rust-lang/rust/pull/46788
Add tests checking that "priority" of qpath recovery is higher than priority of unary and binary operators
Fix regressed parsing of paths with fn-like generic arguments
r? @estebank
Implement non-mod.rs mod statements
Fixes https://github.com/rust-lang/rust/issues/45385, cc https://github.com/rust-lang/rust/issues/44660
This will fail tidy right now because it doesn't recognize my UI tests as feature-gate tests. However, I'm not sure if compile-fail will work out either because compile-fail usually requires there to be error patterns in the top-level file, which isn't possible with this feature. What's the recommended way to handle this?
