about summary refs log tree commit diff
path: root/compiler/rustc_parse/src/parser
AgeCommit message (Collapse)AuthorLines
2023-09-14Auto merge of #115677 - matthewjasper:let-expr-recovery, r=b-naberbors-121/+257
Improve invalid let expression handling - Move all of the checks for valid let expression positions to parsing. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress some later errors and MIR construction for invalid let expressions. - Fix a (drop) scope issue that was also responsible for #104172. Fixes #104172 Fixes #104868
2023-09-13Address review commentsMatthew Jasper-4/+13
- Add doc comment to new type - Restore "only supported directly in conditions of `if` and `while` expressions" note - Rename variant with clearer name
2023-09-12Only suggest turbofish in patterns if we may recoverLeón Orell Valerian Liehr-1/+2
2023-09-11Reduce double errors for invalid let expressionsMatthew Jasper-3/+2
Previously some invalid let expressions would result in both a feature error and a parsing error. Avoid this and ensure that we only emit the parsing error when this happens.
2023-09-11Move let expression checking to parsingMatthew Jasper-121/+249
There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-06Rollup merge of #115596 - nnethercote:two-small-changes, r=lqdMatthias Krüger-1/+1
A small change A small change I made while poking around the code. r? `@lqd`
2023-09-06Rollup merge of #115473 - gurry:113110-expected-item, r=compiler-errorsMatthias Krüger-4/+8
Add explanatory note to 'expected item' error Fixes #113110 It changes the diagnostic from this: ``` error: expected item, found `5` --> ../test.rs:1:1 | 1 | 5 | ^ expected item ``` to this: ``` error: expected item, found `5` --> ../test.rs:1:1 | 1 | 5 | ^ expected item | = note: items are things that can appear at the root of a module = note: for a full list see https://doc.rust-lang.org/reference/items.html ```
2023-09-06Adjust `to_attr_token_stream`.Nicholas Nethercote-1/+1
It uses `once` chained with `(0..self.num_calls).map(...)` followed by `.take(self.num_calls`. I found this hard to read. It's simpler to just use `repeat_with`.
2023-09-06Add explanatory note to 'expected item' errorGurinder Singh-4/+8
2023-09-06Auto merge of #115371 - matthewjasper:if-let-guard-parsing, r=cjgillotbors-3/+1
Make if let guard parsing consistent with normal guards - Add tests that struct expressions are not allowed in `if let` and `while let` (no change, consistent with `if` and `while`) - Allow struct expressions in `if let` guards (consistent with `if` guards). r? `@cjgillot` Closes #93817 cc #51114
2023-08-30Rollup merge of #115347 - y21:generic-bound-impl-trait-ty, r=compiler-errorsMatthias Krüger-12/+26
suggest removing `impl` in generic trait bound position rustc already does this recovery in type param position (`<T: impl Trait>` -> `<T: Trait>`). This PR also adds that suggestion in trait bound position (e.g. `where T: impl Trait` or `trait Trait { type Assoc: impl Trait; }`)
2023-08-30Rollup merge of #114704 - bvanjoi:fix-114636, r=compiler-errorsMatthias Krüger-13/+3
parser: not insert dummy field in struct Fixes #114636 This PR eliminates the dummy field, initially introduced in #113999, thereby enabling unrestricted use of `ident.unwrap()`. A side effect of this action is that we can only report the error of the first macro invocation field within the struct node. An alternative solution might be giving a virtual name to the macro, but it appears more complex.(https://github.com/rust-lang/rust/issues/114636#issuecomment-1670228715). Furthermore, if you think https://github.com/rust-lang/rust/issues/114636#issuecomment-1670228715 is a better solution, feel free to close this PR.
2023-08-29suggest removing `impl` in generic trait bound positiony21-12/+26
2023-08-28Allow stuct literals in if let guardsMatthew Jasper-3/+1
This is consistent with normal match guards.
2023-08-24Auto merge of #115131 - frank-king:feature/unnamed-fields-lite, r=petrochenkovbors-3/+51
Parse unnamed fields and anonymous structs or unions (no-recovery) It is part of #114782 which implements #49804. Only parse anonymous structs or unions in struct field definition positions. r? `@petrochenkov`
2023-08-24Parse unnamed fields and anonymous structs or unionsFrank King-3/+51
Anonymous structs or unions are only allowed in struct field definitions. Co-authored-by: carbotaniuman <41451839+carbotaniuman@users.noreply.github.com>
2023-08-21discard dummy field for macro invocation when parse structbohan-13/+3
2023-08-19Fix a stack overflow with long else if chainsJohn Kåre Alsaker-1/+2
2023-08-18Auto merge of #114915 - nnethercote:Nonterminal-cleanups, r=petrochenkovbors-80/+82
`Nonterminal`-related cleanups In #114647 I am trying to remove `Nonterminal`. It has a number of preliminary cleanups that are worth merging even if #114647 doesn't merge, so let's do them in this PR. r? `@petrochenkov`
2023-08-18Rename `NtOrTt` as `ParseNtResult`.Nicholas Nethercote-5/+5
It's more descriptive, and future-proofs it if/when additional variants get added.
2023-08-18Use `interpolated_or_expr_span` in one suitable place.Nicholas Nethercote-7/+1
2023-08-18Refactor `interpolated_or_expr_span`.Nicholas Nethercote-20/+12
It's much more complicated than it needs to be, and it doesn't modify the expression. We can do the `Result` handling outside of it, and change it to just return a span. Also fix an errant comma that makes the comment hard to read.
2023-08-17Simplify a `match`.Nicholas Nethercote-4/+1
`may_be_ident` is true for `NtPath` and `NtMeta`, so we don't need to check for them separately.
2023-08-17Make some `match`es exhaustive in `nonterminal.rs`.Nicholas Nethercote-5/+20
For ones matching more than one or two variants, this is easier to think about.
2023-08-17Use `Nonterminal::*` in `nonterminal.rs`.Nicholas Nethercote-26/+17
It makes the code more readable.
2023-08-17Remove unnecessary braces on `PatWithOr` patterns.Nicholas Nethercote-4/+4
2023-08-17Add some useful comments to `Parser::look_ahead`.Nicholas Nethercote-8/+23
2023-08-17Rename `parse_no_question_mark_recover`.Nicholas Nethercote-2/+2
Adding a `ty_` makes its purpose much clearer, and consistent with other `parse_ty_*` functions.
2023-08-17Remove outdated comment.Nicholas Nethercote-2/+0
All nonterminals collect and store tokens now. (Unless they are very simple, e.g. single-token, and can precisely recover them without collecting.)
2023-08-16Fix bad suggestion when wrong parentheses around a dyn traityukang-10/+12
2023-08-13Remove reached_eof from ParseSessbjorn3-13/+0
It was only ever set in a function which isn't called anywhere.
2023-08-08inlined kinddarklyspaced-2/+1
2023-08-07always return ExprKind::Errdarklyspaced-6/+1
2023-08-04Rollup merge of #114434 - Nilstrieb:indexing-spans, r=est31Matthias Krüger-4/+7
Improve spans for indexing expressions fixes #114388 Indexing is similar to method calls in having an arbitrary left-hand-side and then something on the right, which is the main part of the expression. Method calls already have a span for that right part, but indexing does not. This means that long method chains that use indexing have really bad spans, especially when the indexing panics and that span in coverted into a panic location. This does the same thing as method calls for the AST and HIR, storing an extra span which is then put into the `fn_span` field in THIR. r? compiler-errors
2023-08-04Improve spans for indexing expressionsNilstrieb-4/+7
Indexing is similar to method calls in having an arbitrary left-hand-side and then something on the right, which is the main part of the expression. Method calls already have a span for that right part, but indexing does not. This means that long method chains that use indexing have really bad spans, especially when the indexing panics and that span in coverted into a panic location. This does the same thing as method calls for the AST and HIR, storing an extra span which is then put into the `fn_span` field in THIR.
2023-08-04Rollup merge of #113999 - Centri3:macro-arm-expand, r=wesleywiserMatthias Krüger-24/+62
Specify macro is invalid in certain contexts Adds a note when a macro is used where it really shouldn't be. Closes #113766
2023-08-03Rollup merge of #114300 - MU001999:fix/turbofish-pat, r=estebankMatthias Krüger-28/+52
Suggests turbofish in patterns Fixes #114112 r? ```@estebank```
2023-08-03Rollup merge of #114237 - bvanjoi:fix-114219, r=cjgillotMatthias Krüger-4/+11
parser: more friendly hints for handling `async move` in the 2015 edition Fixes #114219 An error is emitted when encountering an async move block in the 2015 edition. Another appropriate location to raise an error is after executing [let path = this.parse_path(PathStyle::Expr)?](https://github.com/rust-lang/rust/blob/master/compiler/rustc_parse/src/parser/stmt.rs#L152), but it seems somewhat premature to invoke `create_err` at that stage.
2023-08-03Reduce arbitrary self type suggestionsr0cky-15/+3
2023-08-03Avoid too many expected symbols and reduce `None`sr0cky-58/+52
2023-08-03Apply suggestionsr0cky-2/+4
2023-08-02Add test for enum with fieldsCatherine Flores-6/+1
2023-08-03Remove `MacDelimiter`.Nicholas Nethercote-9/+6
It's the same as `Delimiter`, minus the `Invisible` variant. I'm generally in favour of using types to make impossible states unrepresentable, but this one feels very low-value, and the conversions between the two types are annoying and confusing. Look at the change in `src/tools/rustfmt/src/expr.rs` for an example: the old code converted from `MacDelimiter` to `Delimiter` and back again, for no good reason. This suggests the author was confused about the types.
2023-08-03Keep the suggestion for wrong arbitrary self typesMu001999-54/+85
2023-08-02Avoid an unnecessary local variable.Nicholas Nethercote-2/+1
2023-08-02Move `TokenCursor::break_last_token` into `Parser`.Nicholas Nethercote-39/+25
Similar to the last commit, it's more of a `Parser`-level concern than a `TokenCursor`-level concern. And the struct size reductions are nice. After this change, `TokenCursor` is as minimal as possible (two fields and two methods) which is nice.
2023-08-02Move `TokenCursor::num_next_calls` into `Parser` and rename it.Nicholas Nethercote-18/+14
It's more of a `Parser`-level concern than a `TokenCursor`-level concern. Also, `num_bump_calls` is a more accurate name, because it's incremented in `Parser::bump`.
2023-08-02Inline and remove `parse_all_token_trees`.Nicholas Nethercote-10/+1
It has a single call site.
2023-08-02`parse_all_token_trees` cannot fail.Nicholas Nethercote-2/+2
2023-08-01Auto merge of #114273 - nnethercote:move-doc-comment-desugaring, r=petrochenkovbors-78/+13
Move doc comment desugaring out of `TokenCursor`. It's awkward that `TokenCursor` sometimes desugars doc comments on the fly, but usually doesn't. r? `@petrochenkov`
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 13:23:46 +0000