rust/compiler/rustc_parse/src/parser, branch perf-tmphttps://github.com/rust-lang/rust
http://git.dreamy.place/mirrors/rust/atom?h=perf-tmp2025-10-04T09:31:00+00:00Unrolled build for #1472452025-10-04T09:31:00+00:00Rust timing botrust-timer@users.noreply.github.com2025-10-04T09:31:00+00:00urn:sha1:823632bbfbb2941cdc3c69130f19b39ea565a7aa
Rollup merge of #147245 - karolzwolak:only-replace-intended-bar-not-all-in-pattern, r=lcnr
only replace the intended comma in pattern suggestions
Only suggest to replace the intended comma, not all bars in the pattern.
Fixes rust-lang/rust#143330.
This continues rust-lang/rust#143331, the credit for making the fix goes to `@A4-Tacks.` I just blessed tests and added a regression test.
bring back plural 'alternatives' in suggestion message2025-10-02T18:24:34+00:00Karol Zwolakkarolzwolak7@gmail.com2025-10-02T18:24:34+00:00urn:sha1:d1d7b9472a18780499162b4a91beea729bc2c13bRollup merge of #147004 - estebank:ascription-in-pat, r=fee1-dead2025-10-02T08:27:50+00:00Matthias Krüger476013+matthiaskrgr@users.noreply.github.com2025-10-02T08:27:50+00:00urn:sha1:e041b2c07830a561d3224338aec4c9e520791e67
Tweak handling of "struct like start" where a struct isn't supported
This improves the case where someone tries to write a `match` expr where the patterns have type ascription syntax. Makes them less verbose, by giving up on the first encounter in the block, and makes them more accurate by only treating them as a struct literal if successfully parsed as such.
Before, encountering something like `match a { b:` would confuse the parser and think everything after `match` *must* be a struct, and if it wasn't it would generate a cascade of unnecessary diagnostics.
Fix diagnostics str::replace comma to bar2025-10-01T20:45:16+00:00A4-Tackswdsjxhno1001@163.com2025-07-02T09:18:57+00:00urn:sha1:4735c2184c72b8b3a8bad642407a74d4b19838fbUse `Iterator::eq` and (dogfood) `eq_by` in compiler and library2025-09-29T05:08:05+00:00Yotam Ofekyotam.ofek@gmail.com2025-09-27T17:57:50+00:00urn:sha1:68a7c250788833305f73f816b284aafa9e62370aSimplify logic slightly2025-09-27T00:42:11+00:00Esteban Küberesteban@kuber.com.ar2025-09-24T23:25:29+00:00urn:sha1:bb48c162b62ce20c5f51b6a435ca2ba7bb918d7eTweak handling of "struct like start" where a struct isn't supported2025-09-24T21:31:23+00:00Esteban Küberesteban@kuber.com.ar2025-09-24T21:06:54+00:00urn:sha1:43057698c12e8ceab1f49eff8a3e5a38cc05f7db
This improves the case where someone tries to write a `match` expr where the patterns have type ascription syntax. Makes them less verbose, by giving up on the first encounter in the block, and makes them more accurate by only treating them as a struct literal if successfuly parsed as such.
Detect top-level `...` in argument type2025-09-16T18:38:08+00:00Esteban Küberesteban@osdyne.com2025-09-16T18:38:08+00:00urn:sha1:e9270e3cba3da56d4d83ed74f648e53b041cb263
When writing something like the expression `|_: ...| {}`, we now detect the `...` during parsing explicitly instead of relying on the detection in `parse_ty_common` so that we don't talk about "nested `...` are not supported".
```
error: unexpected `...`
--> $DIR/no-closure.rs:6:35
|
LL | const F: extern "C" fn(...) = |_: ...| {};
| ^^^
|
= note: only `extern "C"` and `extern "C-unwind"` functions may have a C variable argument list
```
Detect attempt to use var-args in closure2025-09-15T09:53:29+00:00Esteban Küberesteban@osdyne.com2025-09-15T09:53:29+00:00urn:sha1:9405e76431374e25077b374ed0cd9c920a1c0f4f
```
error: unexpected `...`
--> $DIR/varargs-in-closure-isnt-supported.rs:5:20
|
LL | let mut lol = |...| ();
| ^^^ not a valid pattern
|
= note: C-variadic type `...` is not allowed here
```
Rollup merge of #146422 - fmease:less-greedy-maybe-const-bounds, r=estebank2025-09-11T04:06:32+00:00Stuart CookZalathar@users.noreply.github.com2025-09-11T04:06:32+00:00urn:sha1:d037d1097fe62a9ec5dfcb211cbe334f2d635428
Less greedily parse `[const]` bounds
> [!IMPORTANT]
> If you're coming here from any beta backport nomination thread on Zulip, only the last commit is truly relevant (the first commit doesn't need to be backported, it only contains test modifications)!
Don't consider `[` to start a bound, only consider `[const]` in its entirety to do so. This drastically reduces (but doesn't eliminate!) the chance of *real* breakages. Like `const`, `~const` and `async` before, `[const]` unavoidably brings along theoretical breakages, see preexisting tests: `macro-const-trait-bound-theoretical-regression.rs` and `macro-async-trait-bound-theoretical-regression.rs`.
Side note: It's unfortunate that we have to do this but apart from the known fact that MBE hurts forward compatibility, the `[const]` syntax is simply a bit scuffed (also CC'ing https://github.com/rust-lang/rust/issues/146122, section (3)).
Fixes [after beta backport] rust-lang/rust#146417.
* 1st commit: Restore the original test intentions of several preexisting related tests that were unfortunately lost over time
* I've added a bunch of SCREAMING comments to make it less likely to be lost again
* CC PR rust-lang/rust#119099 which added most of these tests
* CC [#144409 (comment)](https://github.com/rust-lang/rust/pull/144409#discussion_r2337587513) for further context (NB: It's not the only PR that negatively affected the test intention)
* 2nd commit: Actually address the regression
r? `@oli-obk` or anyone