Emit ForbiddenBound fatally if meeting complex bound#149728
Emit ForbiddenBound fatally if meeting complex bound#149728rust-bors[bot] merged 1 commit intorust-lang:mainfrom
Conversation
|
r? @wesleywiser rustbot has assigned @wesleywiser. Use |
This comment has been minimized.
This comment has been minimized.
|
@rustbot reroll |
|
@rustbot author |
|
Reminder, once the PR becomes ready for a review, use |
|
@rustbot review |
|
@rusbot author |
|
@rustbot blocked on #149728 (comment) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Hi @jdonszelmann, in the lastest rough change, I tried to filter nested items in the bound, and not lower them to hir.
But there still be errors, because they still have Concrete content of the new ICE is: |
|
I think at least it's more difficult than I expected. Do you have any suggestions? |
This comment has been minimized.
This comment has been minimized.
|
@bors r- |
|
This pull request was unapproved. Auto build was cancelled due to unapproval. Cancelled workflows: |
…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
…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
…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
|
@jdonszelmann Hi, what's your opinion on the next step? Do a crater run and nominate it for T-lang discussion, or back to directly emitting a fatal error? @rustbot review |
Rollup merge of #153624 - fmease:ping-me-on-parser-changes, 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. #149728 (review) (2026) * caught before merge but after approval * PR unapproved for now 2. #152501 (2026) * caught after merge of #149489 * fixed & backported 3. #152499 (2026) * caught after merge of #149667 * fixed & backported 4. #151960 (comment) (2026) * caught right after submission * the approach was thus changed 5. #148238 (2025) * caught after merge of #118947 * still unaddressed 6. #144386 (review) (2025) * caught right after submission * crater & T-lang were activated by me 7. #119042 (comment) (2023) * caught right after submission * the approach was thus changed 8. #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 #146417 before PR #139858 was merged despite having skimmed its diff and more importantly, I as a reviewer missed the blatantly obvious #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., #152499 and #152820 were found this way, more to come). I'm pretty invested, let's say. r? me
|
I guess a fatal error it is. This is a wild ride, but if we might implement this at some point and given that its rare, a fatal error seems like the way to go |
|
@rustbot author |
This comment has been minimized.
This comment has been minimized.
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
@rustbot review |
|
@bors r+ |
This comment has been minimized.
This comment has been minimized.
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 85e19b8 (parent) -> 91021cc (this PR) Test differencesShow 6 test diffsStage 1
Stage 2
Additionally, 4 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 91021ccc790478a1a89c003e7d32b8d155ae6aae --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (91021cc): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary 0.9%, secondary -0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -0.3%, secondary -4.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 480.745s -> 479.493s (-0.26%) |
View all comments
Fixes #149695
Bounds in binders are denied, hir items won't contain and index them. But nested items in the bounds will still be lowered to hir. And their parents, i.e., the block in bounds is not in hir. So that ICE happens when error handling requires visiting hir parents.
This PR collects hirless def ids and skips them when iterating parents.This PR checks such bounds used in higher ranked binders and emit errorForbiddenBoundwhen parsing. And make sure no such bounds appear in hir.This PR emits this error fatally if meeting complex bound.