TraitKind -> Trait
TyAliasKind -> TyAlias
ImplKind -> Impl
FnKind -> Fn
All `*Kind`s in AST are supposed to be enums.
Tuple structs are converted to braced structs for the types above, and fields are reordered in syntactic order.
Also, mutable AST visitor now correctly visit spans in defaultness, unsafety, impl polarity and constness.
rustc_span: `Ident::invalid` -> `Ident::empty`
The equivalent for `Symbol`s was renamed some time ago (`kw::Invalid` -> `kw::Empty`), and it makes sense to do the same thing for `Ident`s as well.
Nicer error message if the user attempts to do let...else if
Gives a nice "conditional `else if` is not supported for `let...else`" error when encountering a `let...else if` pattern, as suggested in the [let...else tracking issue](https://github.com/rust-lang/rust/issues/87335#issuecomment-944846205).
"Fix" an overflow in byte position math
r? `@estebank`
help! I fixed the ICE only to brick the diagnostic.
I mean, it was wrong previously (using an already expanded macro span), but it is really bad now XD
Newcomers may write `{1, 2, 3}` for making arrays, and the current error
message is not informative enough to quickly convince them what is
needed to fix the error.
This PR implements a diagnostic for this case, and its output looks like
this:
```text
error: this code is interpreted as a block expression, not an array
--> src/lib.rs:1:22
|
1 | const FOO: [u8; 3] = {
| ______________________^
2 | | 1, 2, 3
3 | | };
| |_^
|
= note: to define an array, one would use square brackets instead of curly braces
help: try using [] instead of {}
|
1 | const FOO: [u8; 3] = [
2 | 1, 2, 3
3 | ];
|
```
Fix#87672
Recover from `Foo(a: 1, b: 2)`
Detect likely `struct` literal using parentheses as delimiters and emit
targeted suggestion instead of type ascription parse error.
Fix#61326.
Revert anon union parsing
Revert PR #84571 and #85515, which implemented anonymous union parsing in a manner that broke the context-sensitivity for the `union` keyword and thus broke stable Rust code.
Fix#88583.
Accept `m!{ .. }.method()` and `m!{ .. }?` statements.
This PR fixes something that I keep running into when using `quote!{}.into()` in a proc macro to convert the `proc_macro2::TokenStream` to a `proc_macro::TokenStream`:
Before:
```
error: expected expression, found `.`
--> src/lib.rs:6:6
|
4 | quote! {
5 | ...
6 | }.into()
| ^ expected expression
```
After:
```
```
(No output, compiles fine.)
---
Context:
For expressions like `{ 1 }` and `if true { 1 } else { 2 }`, we accept them as full statements without a trailing `;`, which means the following is not accepted:
```rust
{ 1 } - 1 // error
```
since that is parsed as two statements: `{ 1 }` and `-1`. Syntactically correct, but the type of `{ 1 }` should be `()` as there is no `;`.
However, for specifically `.` and `?` after the `}`, we do [continue parsing it as an expression](13db8440bb/compiler/rustc_parse/src/parser/expr.rs (L864-L876)):
```rust
{ "abc" }.len(); // ok
```
For braced macro invocations, we do not do this:
```rust
vec![1, 2, 3].len(); // ok
vec!{1, 2, 3}.len(); // error
```
(It parses `vec!{1, 2, 3}` as a full statement, and then complains about `.len()` not being a valid expression.)
This PR changes this to also look for a `.` and `?` after a braced macro invocation. We can be sure the macro is an expression and not a full statement in those cases, since no statement can start with a `.` or `?`.
