Permit attributes on 'if' expressions
Previously, attributes on 'if' expressions (e.g. `#[attr] if true {}`)
were disallowed during parsing. This made it impossible for macros to
perform any custom handling of such attributes (e.g. stripping them
away), since a compilation error would be emitted before they ever had a
chance to run.
This PR permits attributes on 'if' expressions ('if-attrs' from here on).
Both built-in attributes (e.g. `#[allow]`, `#[cfg]`) and proc-macro attributes are supported.
We still do *not* accept attributes on 'other parts' of an if-else
chain. That is, the following code snippet still fails to parse:
```rust
if true {} #[attr] else if false {} else #[attr] if false {} #[attr]
else {}
```
Closes https://github.com/rust-lang/rust/issues/68618
On mismatched delimiters, only point at empty blocks that are in the same line
We point at empty blocks when we have mismatched braces to detect cases where editors auto insert `}` after writing `{`. Gate this to only the case where the entire span is in the same line so we never point at explicitly empty blocks.
Parse & reject postfix operators after casts
This adds an explicit error messages for when parsing `x as Type[0]` or similar expressions. Our add an extra parse case for parsing any postfix operator (dot, indexing, method calls, await) that triggers directly after parsing `as` expressions.
My friend and I worked on this together, but they're still deciding on a github username and thus I'm submitting this for both of us.
It will immediately error out, but will also provide the rest of the parser with a useful parse tree to deal with.
There's one decision we made in how this produces the parse tree. In the situation `&x as T[0]`, one could imagine this parsing as either `&((x as T)[0])` or `((&x) as T)[0]`. We chose the latter for ease of implementation, and as it seemed the most intuitive.
Feedback welcome! This is our first change to the parser section, and it might be completely horrible.
Fixes#35813.
Previously, attributes on 'if' expressions (e.g. #[attr] if true {})
were disallowed during parsing. This made it impossible for macros to
perform any custom handling of such attributes (e.g. stripping them
away), since a compilation error would be emitted before they ever had a
chance to run.
This PR permits attributes on 'if' expressions ('if-attrs' from here on).
Both built-in attributes (e.g. `#[allow]`, `#[cfg]`) are supported.
We still do *not* accept attributes on 'other parts' of an if-else
chain. That is, the following code snippet still fails to parse:
```rust
if true {} #[attr] else if false {} else #[attr] if false {} #[attr]
else {}
```
This is a modified version of estebank's suggestion, with a bit of
extra cleanup now that we don't need the different cases for if we can
turn a span into a string or not.
parse: recover `mut (x @ y)` as `(mut x @ mut y)`.
Follow up to https://github.com/rust-lang/rust/pull/68992#discussion_r376829749 and https://github.com/rust-lang/rust/pull/63945.
Specifically, when given `let mut (x @ y)` we recover with `let (mut x @ mut y)` as the suggestion:
```rust
error: `mut` must be attached to each individual binding
--> $DIR/mut-patterns.rs:12:9
|
LL | let mut (x @ y) = 0;
| ^^^^^^^^^^^ help: add `mut` to each binding: `(mut x @ mut y)`
|
= note: `mut` may be followed by `variable` and `variable @ pattern`
```
r? @matthewjasper @estebank
parse: fuse associated and extern items up to defaultness
Language changes:
- The grammar of extern `type` aliases is unified with associated ones, and becomes:
```rust
TypeItem = "type" ident generics {":" bounds}? where_clause {"=" type}? ";" ;
```
Semantic restrictions (`ast_validation`) are added to forbid any parameters in `generics`, any bounds in `bounds`, and any predicates in `where_clause`, as well as the presence of a type expression (`= u8`).
(Work still remains to fuse this with free `type` aliases, but this can be done later.)
- The grammar of constants and static items (free, associated, and extern) now permits the absence of an expression, and becomes:
```rust
GlobalItem = {"const" {ident | "_"} | "static" "mut"? ident} {"=" expr}? ";" ;
```
- A semantic restriction is added to enforce the presence of the expression (the body).
- A semantic restriction is added to reject `const _` in associated contexts.
Together, these changes allow us to fuse the grammar of associated items and extern items up to `default`ness which is the main goal of the PR.
-----------------------
We are now very close to fully fusing the entirely of item parsing and their ASTs. To progress further, we must make a decision: should we parse e.g. `default use foo::bar;` and whatnot? Accepting that is likely easiest from a parsing perspective, as it does not require using look-ahead, but it is perhaps not too onerous to only accept it for `fn`s (and all their various qualifiers), `const`s, `static`s, and `type`s.
r? @petrochenkov
This adds parsing for expressions like 'x as Ty[0]' which will
immediately error out, but still give the rest of the parser a valid
parse tree to continue.
