| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
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
|
|
Add more regression tests
Closes #39618
Closes #51798
Closes #62894
Closes #63952
Closes #68653
r? @Centril
|
|
|
|
Transition macro_legacy_warnings into a hard error
Fixes https://github.com/rust-lang/rust/issues/67098.
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
as a consequence, `trait X { #![attr] }` becomes legal.
|
|
|
|
|
|
|
|
|
|
|
|
use new span for better diagnostics.
|
|
Account for type params on method without parentheses
Account for those type parameters in the structured suggestion when forgetting to call method:
```
error[E0615]: attempted to take value of method `collect` on type `std::vec::IntoIter<_>`
--> $DIR/method-missing-parentheses.rs:2:32
|
LL | let _ = vec![].into_iter().collect::<usize>;
| ^^^^^^^---------
| |
| help: use parentheses to call the method: `collect::<usize>()`
```
|
|
Make issue references consistent
Fixes https://github.com/rust-lang/rust/issues/62976
cc https://github.com/rust-lang/rust/pull/63008
r? @varkor because you reviewed the original pr
|
|
|
|
change an instance of span_bug() to struct_span_err() to avoid ICE
After #67148, the `span_bug()` in `parse_ty_tuple_or_parens()` is reachable because `parse_paren_comma_seq()` can return an `Ok()` even in cases where it encounters an error.
This pull request prevents an ICE in such cases by replacing the `span_bug()` with `struct_span_error()`.
Fixes #68890.
|
|
|
|
including their unnormalized forms.
Add more documentation for them.
|
|
|
|
|
|
stop using BytePos for computing spans in librustc_parse/parser/mod.rs
Computing spans using logic such as `self.token.span.lo() + BytePos(1)` can cause internal compiler errors like #68730 when non-ascii characters are given as input.
#68735 partially addressed this problem, but only for one case. Moreover, its usage of `next_point()` does not actually align with what `bump_with()` expects. For example, given the token `>>=`, we should pass the span consisting of the final two characters `>=`, but `next_point()` advances the span beyond the end of the `=`.
This pull request instead computes the start of the new span by doing `start_point(self.token.span).hi()`. This matches `self.token.span.lo() + BytePos(1)` in the common case where the characters are ascii, and it gracefully handles multibyte characters.
Fixes #68783.
|
|
|
|
|
|
also refactor `FnKind` and `visit_assoc_item` visitors
|
|
Use `next_point` to avoid ICE
Fixes #68730
r? @estebank (I think you're familiar with that)
|
|
parser: syntactically allow `self` in all `fn` contexts
Part of https://github.com/rust-lang/rust/pull/68728.
`self` parameters are now *syntactically* allowed as the first parameter irrespective of item context (and in function pointers). Instead, semantic validation (`ast_validation`) is used.
r? @petrochenkov
|
|
|
|
|
|
Suggest path separator for single-colon typos
This commit adds guidance for when a user means to type a path, but ends
up typing a single colon, such as `<<Impl as T>:Ty>`.
This change seemed pertinent as the current error message is
particularly misleading, emitting `error: unmatched angle bracket`,
despite the angle bracket being matched later on, leaving the user to
track down the typo'd colon.
|
