| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
|
|
parser: Cleanup `Parser::bump_with` and its uses
Follow-up to https://github.com/rust-lang/rust/pull/69006.
r? @Centril
|
|
Rename CodeMap to SourceMap follow up
See https://github.com/rust-lang/rust/issues/51574
|
|
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
|
|
parser: Simplify treatment of macro variables in `Parser::bump`
Follow-up to https://github.com/rust-lang/rust/pull/69006.
Token normalization for `$ident` and `$lifetime` is merged directly into `bump`.
Special "unknown macro variable" diagnostic for unexpected `$`s is removed as preventing legal code from compiling (as a result `bump` also doesn't call itself recursively anymore and can't make `prev_token` inconsistent).
r? @Centril
|
|
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
|
|
They are always set synchronously with normalized tokens now
|
|
|
|
Token normalization is merged directly into `bump`.
Special "unknown macro variable" diagnostic for unexpected `$`s is removed as preventing legal code from compiling.
|
|
|
|
Transition macro_legacy_warnings into a hard error
Fixes https://github.com/rust-lang/rust/issues/67098.
r? @petrochenkov
|
|
[tiny] parser: `macro_rules` is a weak keyword
r? @Centril
|
|
|
|
|
|
|
|
Previously this just errored out on all usages of type ascription,
which isn't helpful.
|
|
This is almost entirely refactoring and message changing, with the
single behavioral change of panicking for unexpected output.
|
|
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.
|
|
|
|
Fixes #68690
When we generate the proc macro harness, we now explicitly recorder the
order in which we generate entries. We then use this ordering data to
deserialize the correct proc-macro-data from the crate metadata.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Currently, we emit a "try adding a comma" suggestion if a comma is
missing in a struct definition. However, we emit no such suggestion if a
comma is missing in a struct initializer.
This commit adds a "try adding a comma" suggestion when we don't find a
comma during the parsing of a struct initializer field.
The change to `src/test/ui/parser/removed-syntax-with-1.stderr` isn't
great, but I don't see a good way of avoiding it.
|
|
expand: misc cleanups and simplifications
Some work I did while trying to understand expand for the purposes of https://github.com/rust-lang/rust/issues/64197.
r? @petrochenkov
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
this also extracts macro item parsers.
|
|
|
|
as a consequence, `trait X { #![attr] }` becomes legal.
|
|
|
|
|
|
|
|
|