rust/compiler/rustc_parse/src/parser, branch 1.74.0https://github.com/rust-lang/rust
http://git.dreamy.place/mirrors/rust/atom?h=1.74.02023-09-28T00:37:20+00:00Tweak wording of missing angle backets in qualified path2023-09-28T00:37:20+00:00Esteban Küberesteban@kuber.com.ar2023-09-28T00:37:20+00:00urn:sha1:3848ffcee7ae74e15e4b68ad0f45a29f1fc170c7Auto merge of #115677 - matthewjasper:let-expr-recovery, r=b-naber2023-09-14T19:56:55+00:00borsbors@rust-lang.org2023-09-14T19:56:55+00:00urn:sha1:dac91a82e146d89fefe94dcbb53cd6c2662e354f
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
Address review comments2023-09-13T15:00:31+00:00Matthew Jaspermjjasper1@gmail.com2023-09-13T15:00:31+00:00urn:sha1:e324a59eb6ba1a7883bf23ff42d425ca96960f2a
- Add doc comment to new type
- Restore "only supported directly in conditions of `if` and `while` expressions" note
- Rename variant with clearer name
Only suggest turbofish in patterns if we may recover2023-09-12T14:38:59+00:00León Orell Valerian Liehrme@fmease.dev2023-09-12T14:30:38+00:00urn:sha1:3ed77e98fa9e9a03940b55b0bbc10615b446f299Reduce double errors for invalid let expressions2023-09-11T16:17:06+00:00Matthew Jaspermjjasper1@gmail.com2023-09-11T16:16:59+00:00urn:sha1:b011a0a13b4354080b3add0bb3f4445ddb8fd13b
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.
Move let expression checking to parsing2023-09-11T15:51:18+00:00Matthew Jaspermjjasper1@gmail.com2023-09-08T10:14:36+00:00urn:sha1:333388fd3c9fa03362a3c2a2675ab521c4ddb1ff
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.
Rollup merge of #115596 - nnethercote:two-small-changes, r=lqd2023-09-06T17:31:50+00:00Matthias Krügermatthias.krueger@famsik.de2023-09-06T17:31:50+00:00urn:sha1:da44234b647115d9056622ef786fe875d1bb684d
A small change
A small change I made while poking around the code.
r? `@lqd`
Rollup merge of #115473 - gurry:113110-expected-item, r=compiler-errors2023-09-06T17:31:48+00:00Matthias Krügermatthias.krueger@famsik.de2023-09-06T17:31:48+00:00urn:sha1:4a31cc859b376b853ab40961c26b99136a6a1e61
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
```
Adjust `to_attr_token_stream`.2023-09-06T07:12:07+00:00Nicholas Nethercoten.nethercote@gmail.com2023-09-06T06:45:58+00:00urn:sha1:42dbc72d7bb0645292d72816d768d1f5365a58ca
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`.
Add explanatory note to 'expected item' error2023-09-06T03:35:07+00:00Gurinder Singhgurinder.singh@1e.com2023-09-06T03:35:07+00:00urn:sha1:6a286e775c51efb5f05bb98ed2df6b9a974574ad