…r=fmease

Ping fmease on parser modifications

From time to time innocuous-seeming PRs get submitted and sometimes even approved that unbeknownst to their author and to reviewers change the grammar of (stable) Rust which would be a breaking change; often they only meant to tweak diagnostics.

I sometimes catch such PRs before they get merged but I want to make it a lot harder for them to slip through the cracks going forward.

I'm going to list recent examples to paint a picture (note: this is not about blame!):

1. rust-lang#149728 (review) (2026)
   * caught before merge but after approval
   * PR unapproved for now
2. rust-lang#152501 (2026)
   * caught after merge of rust-lang#149489
   * fixed & backported
3. rust-lang#152499 (2026)
   * caught after merge of rust-lang#149667
   * fixed & backported
4. rust-lang#151960 (comment) (2026)
   * caught right after submission
   * the approach was thus changed
5. rust-lang#148238 (2025)
   * caught after merge of rust-lang#118947
   * still unaddressed
6. rust-lang#144386 (review) (2025)
   * caught right after submission
   * crater & T-lang were activated by me
7. rust-lang#119042 (comment) (2023)
   * caught right after submission
   * the approach was thus changed
8. rust-lang#103534 (2022)
   * caught way later
   * partially addressed

Why not just post a note without pinging me? Well, due to them not failing CI and generally due to (friendly) botspam, such comments just get lost or sometimes even actively ignored.

Of course, I'm not able to catch everything. E.g., I didn't notice issue rust-lang#146417 before PR rust-lang#139858 was merged despite having skimmed its diff and more importantly, I as a reviewer missed the blatantly obvious rust-lang#144958 before merge.

Separately, off and on over the span of one year I've worked on a Rust parser that now has >99% accuracy/parity with rustc according to some metrics (this includes stable + unstable + internal syntax) and which I'm using to detect such regressions and issues in general among other things (e.g., rust-lang#152499 and rust-lang#152820 were found this way, more to come). I'm pretty invested, let's say.

r? me

…uwer

Rollup of 5 pull requests

Successful merges:

 - #153283 (feat(rustdoc-json): Add optional support for rkyv (de)serialization)
 - #153608 (ast_passes: unsupported arch w/ scalable vectors)
 - #153616 (Update `sysinfo` version to `0.38.4`)
 - #153619 (Update books)
 - #153624 (Ping fmease on parser modifications)

…r=fmease

Ping fmease on parser modifications

From time to time innocuous-seeming PRs get submitted and sometimes even approved that unbeknownst to their author and to reviewers change the grammar of (stable) Rust which would be a breaking change; often they only meant to tweak diagnostics.

I sometimes catch such PRs before they get merged but I want to make it a lot harder for them to slip through the cracks going forward.

I'm going to list recent examples to paint a picture (note: this is not about blame!):

1. rust-lang#149728 (review) (2026)
   * caught before merge but after approval
   * PR unapproved for now
2. rust-lang#152501 (2026)
   * caught after merge of rust-lang#149489
   * fixed & backported
3. rust-lang#152499 (2026)
   * caught after merge of rust-lang#149667
   * fixed & backported
4. rust-lang#151960 (comment) (2026)
   * caught right after submission
   * the approach was thus changed
5. rust-lang#148238 (2025)
   * caught after merge of rust-lang#118947
   * still unaddressed
6. rust-lang#144386 (review) (2025)
   * caught right after submission
   * crater & T-lang were activated by me
7. rust-lang#119042 (comment) (2023)
   * caught right after submission
   * the approach was thus changed
8. rust-lang#103534 (2022)
   * caught way later
   * partially addressed

Why not just post a note without pinging me? Well, due to them not failing CI and generally due to (friendly) botspam, such comments just get lost or sometimes even actively ignored.

Of course, I'm not able to catch everything. E.g., I didn't notice issue rust-lang#146417 before PR rust-lang#139858 was merged despite having skimmed its diff and more importantly, I as a reviewer missed the blatantly obvious rust-lang#144958 before merge.

Separately, off and on over the span of one year I've worked on a Rust parser that now has >99% accuracy/parity with rustc according to some metrics (this includes stable + unstable + internal syntax) and which I'm using to detect such regressions and issues in general among other things (e.g., rust-lang#152499 and rust-lang#152820 were found this way, more to come). I'm pretty invested, let's say.

r? me

Rollup of 8 pull requests

Successful merges:

 - #148562 (In `Option::get_or_insert_with()`, forget the `None` instead of dropping it.)
 - #149931 (rustdoc: don't give depreciation notes special handling)
 - #153608 (ast_passes: unsupported arch w/ scalable vectors)
 - #153609 (Add missing `Diag::with_span_suggestion_with_style` method)
 - #153610 (Only lint unused features if they are unstable)
 - #153616 (Update `sysinfo` version to `0.38.4`)
 - #153619 (Update books)
 - #153624 (Ping fmease on parser modifications)

…r=fmease

Ping fmease on parser modifications

From time to time innocuous-seeming PRs get submitted and sometimes even approved that unbeknownst to their author and to reviewers change the grammar of (stable) Rust which would be a breaking change; often they only meant to tweak diagnostics.

I sometimes catch such PRs before they get merged but I want to make it a lot harder for them to slip through the cracks going forward.

I'm going to list recent examples to paint a picture (note: this is not about blame!):

1. rust-lang#149728 (review) (2026)
   * caught before merge but after approval
   * PR unapproved for now
2. rust-lang#152501 (2026)
   * caught after merge of rust-lang#149489
   * fixed & backported
3. rust-lang#152499 (2026)
   * caught after merge of rust-lang#149667
   * fixed & backported
4. rust-lang#151960 (comment) (2026)
   * caught right after submission
   * the approach was thus changed
5. rust-lang#148238 (2025)
   * caught after merge of rust-lang#118947
   * still unaddressed
6. rust-lang#144386 (review) (2025)
   * caught right after submission
   * crater & T-lang were activated by me
7. rust-lang#119042 (comment) (2023)
   * caught right after submission
   * the approach was thus changed
8. rust-lang#103534 (2022)
   * caught way later
   * partially addressed

Why not just post a note without pinging me? Well, due to them not failing CI and generally due to (friendly) botspam, such comments just get lost or sometimes even actively ignored.

Of course, I'm not able to catch everything. E.g., I didn't notice issue rust-lang#146417 before PR rust-lang#139858 was merged despite having skimmed its diff and more importantly, I as a reviewer missed the blatantly obvious rust-lang#144958 before merge.

Separately, off and on over the span of one year I've worked on a Rust parser that now has >99% accuracy/parity with rustc according to some metrics (this includes stable + unstable + internal syntax) and which I'm now using to detect such regressions and issues in general among other things (e.g., rust-lang#152499 and rust-lang#152820 were found this way, more to come). I'm pretty invested, let's say.

r? me

Rollup of 7 pull requests

Successful merges:

 - #149931 (rustdoc: don't give depreciation notes special handling)
 - #153608 (ast_passes: unsupported arch w/ scalable vectors)
 - #153609 (Add missing `Diag::with_span_suggestion_with_style` method)
 - #153610 (Only lint unused features if they are unstable)
 - #153616 (Update `sysinfo` version to `0.38.4`)
 - #153619 (Update books)
 - #153624 (Ping fmease on parser modifications)