about summary refs log tree commit diff
path: root/compiler/rustc_parse/src/parser
AgeCommit message (Collapse)AuthorLines
2023-11-08Rollup merge of #117282 - clubby789:recover-wrong-function-header, r=TaKO8KiGuillaume Gomez-3/+37
Recover from incorrectly ordered/duplicated function keywords Fixes #115714
2023-11-07Auto merge of #117297 - clubby789:fn-trait-missing-paren, r=TaKO8Kibors-0/+12
Give a better diagnostic for missing parens in Fn* bounds Fixes #108109 It would be nice to try and recover here, but I'm not sure it's worth the effort, especially as the bounds on the recovered function would be incorrect.
2023-11-04fmtDinu Blanovschi-3/+1
2023-11-04feat(hir): Store the `Span` of the `move` keywordDinu Blanovschi-1/+4
2023-11-03Auto merge of #117507 - nnethercote:rustc_span, r=Nilstriebbors-10/+10
`rustc_span` cleanups Just some things I found while looking over this crate. r? `@oli-obk`
2023-11-02Minimize `pub` usage in `source_map.rs`.Nicholas Nethercote-10/+10
Most notably, this commit changes the `pub use crate::*;` in that file to `use crate::*;`. This requires a lot of `use` items in other crates to be adjusted, because everything defined within `rustc_span::*` was also available via `rustc_span::source_map::*`, which is bizarre. The commit also removes `SourceMap::span_to_relative_line_string`, which is unused.
2023-11-01Rollup merge of #117298 - clubby789:fn-missing-params, r=petrochenkovMatthias Krüger-0/+10
Recover from missing param list in function definitions Addresses the other issue mentioned in #108109
2023-11-01Auto merge of #117289 - estebank:issue-72298, r=cjgillotbors-1/+33
Account for `ref` and `mut` in the wrong place for pattern ident renaming If the user writes `S { ref field: name }` instead of `S { field: ref name }`, we suggest the correct code. Fix #72298.
2023-11-01Give a better diagnostic for missing parens in Fn* boundsclubby789-0/+12
2023-11-01Recover from missing param list in function definitionsclubby789-0/+10
2023-10-31Rollup merge of #116712 - estebank:issue-116252, r=petrochenkovMatthias Krüger-3/+9
When encountering unclosed delimiters during lexing, check for diff markers Fix #116252.
2023-10-30Talk about `gen fn` in diagnostics about `gen fn`Oli Scherer-1/+1
2023-10-30When encountering unclosed delimiters during parsing, check for diff markersEsteban Küber-3/+9
Fix #116252.
2023-10-30Account for `ref` and `mut` in the wrong place for pattern ident renamingEsteban Küber-1/+33
If the user writes `S { ref field: name }` instead of `S { field: ref name }`, we suggest the correct code. Fix #72298.
2023-10-29Auto merge of #116889 - MU001999:master, r=petrochenkovbors-0/+2
Eat close paren if capture_cfg to avoid unbalanced parens Fixes #116781
2023-10-29Auto merge of #116447 - oli-obk:gen_fn, r=compiler-errorsbors-13/+43
Implement `gen` blocks in the 2024 edition Coroutines tracking issue https://github.com/rust-lang/rust/issues/43122 `gen` block tracking issue https://github.com/rust-lang/rust/issues/117078 This PR implements `gen` blocks that implement `Iterator`. Most of the logic with `async` blocks is shared, and thus I renamed various types that were referring to `async` specifically. An example usage of `gen` blocks is ```rust fn foo() -> impl Iterator<Item = i32> { gen { yield 42; for i in 5..18 { if i.is_even() { continue } yield i * 2; } } } ``` The limitations (to be resolved) of the implementation are listed in the tracking issue
2023-10-28restore snapshot when parse_param_generalMu001999-0/+2
2023-10-27Recover from incorrectly ordered/duplicated function keywordsclubby789-3/+37
2023-10-27Rollup merge of #117212 - clubby789:fix-ternary-recover, r=compiler-errorsMatthias Krüger-13/+13
Properly restore snapshot when failing to recover parsing ternary If the recovery parsed an expression, then failed to eat a `:`, it would return `false` without restoring the snapshot. Fix this by always restoring the snapshot when returning `false`. Draft for now because I'd like to try and improve this recovery further. Fixes #117208
2023-10-27Handle `move` generatorsOli Scherer-11/+8
2023-10-27Feature gate `gen` blocks, even in 2024 editionOli Scherer-1/+2
2023-10-27Add gen blocks to ast and do some broken ast loweringOli Scherer-18/+14
2023-10-26Recover ternary expression as errorclubby789-9/+11
2023-10-26Properly restore snapshot when failing to recover parsing ternaryclubby789-4/+2
2023-10-26Reserve `gen` keyword for `gen {}` blocks and `gen fn` in 2024 editionOli Scherer-2/+38
2023-10-25Avoid unbounded O(n^2) when parsing nested type argsEsteban Küber-6/+25
When encountering code like `f::<f::<f::<f::<f::<f::<f::<f::<...` with unmatched closing angle brackets, add a linear check that avoids the exponential behavior of the parse recovery mechanism. Fix #117080.
2023-10-20s/generator/coroutine/Oli Scherer-1/+1
2023-10-20Move where doc comment meant as comment checkEsteban Küber-18/+21
The new place makes more sense and covers more cases beyond individual statements. ``` error: expected one of `.`, `;`, `?`, `else`, or an operator, found doc comment `//!foo --> $DIR/doc-comment-in-stmt.rs:25:22 | LL | let y = x.max(1) //!foo | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected one of `.`, `;`, `?`, `else`, or an operator | help: add a space before `!` to write a regular comment | LL | let y = x.max(1) // !foo | + ``` Fix #65329.
2023-10-15Auto merge of #116688 - compiler-errors:rustfmt-up, r=WaffleLapkin,Nilstriebbors-133/+160
Format all the let-chains in compiler crates Since rust-lang/rustfmt#5910 has landed, soon we will have support for formatting let-chains (as soon as rustfmt syncs and beta gets bumped). This PR applies the changes [from master rustfmt to rust-lang/rust eagerly](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/out.20formatting.20of.20prs/near/374997516), so that the next beta bump does not have to deal with a 200+ file diff and can remain concerned with other things like `cfg(bootstrap)` -- #113637 was a pain to land, for example, because of let-else. I will also add this commit to the ignore list after it has landed. The commands that were run -- I'm not great at bash-foo, but this applies rustfmt to every compiler crate, and then reverts the two crates that should probably be formatted out-of-tree. ``` ~/rustfmt $ ls -1d ~/rust/compiler/* | xargs -I@ cargo run --bin rustfmt -- `@/src/lib.rs` --config-path ~/rust --edition=2021 # format all of the compiler crates ~/rust $ git checkout HEAD -- compiler/rustc_codegen_{gcc,cranelift} # revert changes to cg-gcc and cg-clif ``` cc `@rust-lang/rustfmt` r? `@WaffleLapkin` or `@Nilstrieb` who said they may be able to review this purely mechanical PR :> cc `@Mark-Simulacrum` and `@petrochenkov,` who had some thoughts on the order of operations with big formatting changes in https://github.com/rust-lang/rust/pull/95262#issue-1178993801. I think the situation has changed since then, given that let-chains support exists on master rustfmt now, and I'm fairly confident that this formatting PR should land even if *bootstrap* rustfmt doesn't yet format let-chains in order to lessen the burden of the next beta bump.
2023-10-13Auto merge of #116645 - estebank:issue-116608, r=oli-obkbors-3/+74
Detect ruby-style closure in parser When parsing a closure without a body that is surrounded by a block, suggest moving the opening brace after the closure head. Fix #116608.
2023-10-13Format all the let chains in compilerMichael Goulet-133/+160
2023-10-12Detect ruby-style closure in parserEsteban Küber-3/+74
When parsing a closure without a body that is surrounded by a block, suggest moving the opening brace after the closure head. Fix #116608.
2023-10-12Rename `Token::is_op` as `Token::is_punct`.Nicholas Nethercote-1/+1
For consistency with `proc_macro::Punct`.
2023-10-06Rollup merge of #116400 - estebank:issue-78585, r=WaffleLapkinJubilee-19/+74
Detect missing `=>` after match guard during parsing ``` error: expected one of `,`, `:`, or `}`, found `.` --> $DIR/missing-fat-arrow.rs:25:14 | LL | Some(a) if a.value == b { | - while parsing this struct LL | a.value = 1; | -^ expected one of `,`, `:`, or `}` | | | while parsing this struct field | help: try naming a field | LL | a: a.value = 1; | ++ help: you might have meant to start a match arm after the match guard | LL | Some(a) if a.value == b => { | ++ ``` Fix #78585.
2023-10-04Point to where missing return type should goMichael Goulet-1/+1
2023-10-04review commentsEsteban Küber-3/+2
2023-10-03Detect missing `=>` after match guard during parsingEsteban Küber-19/+75
``` error: expected one of `,`, `:`, or `}`, found `.` --> $DIR/missing-fat-arrow.rs:25:14 | LL | Some(a) if a.value == b { | - while parsing this struct LL | a.value = 1; | -^ expected one of `,`, `:`, or `}` | | | while parsing this struct field | help: try naming a field | LL | a: a.value = 1; | ++ help: you might have meant to start a match arm after the match guard | LL | Some(a) if a.value == b => { | ++ ``` Fix #78585.
2023-10-03Gate against auto traits pre-expansionMichael Goulet-1/+6
2023-09-28Tweak wording of missing angle backets in qualified pathEsteban Küber-4/+3
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; }`)
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-15 16:06:45 +0000