-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a comment pointing to ICE-136223 #136397
Add a comment pointing to ICE-136223 #136397
Conversation
rustbot has assigned @petrochenkov. Use |
r? @Nadrieril |
cc @dianne |
While this fix would work, this is fixing the wrong thing imo: we should be able to compute this cap regardless of features. I'm guessing removing the bug! call would suffice, or make it conditional ont he features for which it makes sense |
oh no, I thought I already fixed this. it completely slipped my mind that it might need a backport. or maybe I messed up with the fix. I'm sorry! I'll try reproducing this myself, but #135434 should already make the debug assert depend on currently enabled feature gates (see a56f9ad and #135434 (comment)). it's merged, so if you pull from master, you should see this: #[cfg(debug_assertions)]
if def_br == ByRef::Yes(Mutability::Mut)
&& max_ref_mutbl != MutblCap::Mut
&& self.downgrade_mut_inside_shared()
{
span_bug!(pat.span, "Pattern mutability cap violated!");
} Edit: I can't reproduce it anymore, so I think it is indeed already fixed. |
Thanks both! |
I agree there should be a regression test. Technically, the test is present in-tree here already: rust/tests/ui/pattern/rfc-3627-match-ergonomics-2024/experimental/borrowck-errors.rs Line 35 in 8a8b464
|
@dianne |
Ahh ok that makes more sense, I was indeed sure we had this test in our test suite. I didn't consider the possible race condition. |
a9a2dec
to
d65b564
Compare
I reverted my change/test, and added a comment to borrowck-errors.rs. |
@rustbot review |
This will clash with #136577. Once that is merged, could you rebase and squash this PR? |
Signed-off-by: Shunpoco <[email protected]>
d65b564
to
ba12489
Compare
I've done 😸 |
alright, thank you :) @bors r+ |
@bors rollup |
&mut
inside &
should not panic by Pattern mutability cap violated!
assertion…mutability-cap-violated, r=Nadrieril Add a comment pointing to ICE-136223 Fixes rust-lang#136223 ## Steps how the ICE happen This explanation is based on the test case `&Some(Some(x)) = &Some(&mut Some(0))`. The case should fail with E0596 error, but it catches the debug assertion instead. 1. For the first `&`: In check_pat_ref(), the value max_ref_mutbl becomes MutblCap::Not ([here](https://github.com/rust-lang/rust/blob/fdd1a3b02687817cea41f6bacae3d5fbed2b2cd0/compiler/rustc_hir_typeck/src/pat.rs#L2394-L2396)). Once max_ref_mutbl becomes Not, it will never be back to MutblCap::Mut. 2. For `&mut`: In peel_off_references(), because Some(x) doesn't have `&` nor `&mut`, `&mut` in `&mut Some(0)` is not consumed then default_binding_mode (def_br) becomes `ByRef::Yes(Mutability::Mut)` (around [here](https://github.com/rust-lang/rust/blob/fdd1a3b02687817cea41f6bacae3d5fbed2b2cd0/compiler/rustc_hir_typeck/src/pat.rs#L519-L536)). This will be inherited to the next step. So this pattern has the mismatch between `def_br=Yes(Mut)` and `max_ref_mutbl=Not` now. 3. For the value `0`: Because of the step 2, the default_binding_mode is `Yes(Mut)`, but max_ref_mutbl is `Not` from the step 1. It causes the assertion error [here](https://github.com/rust-lang/rust/blob/fdd1a3b02687817cea41f6bacae3d5fbed2b2cd0/compiler/rustc_hir_typeck/src/pat.rs#L427-L430). ## What this PR fixes Step 1 has happened from [this commit](rust-lang@e2f3ce9) by deleting `no_ref_mut_behind_and` from the if block. In my understanding, after RFC3627 is released, step 1 should happen not only 2024 edition but also other editions to track MutblCap value. But for now, it should not happen for non-2024 edition. So I put it back. NOTE: I think there is another solution - We should return an E0596 error in calc_default_binding_mode() instead of the debug assertion. Since the assertion is caused by the mismatch between `def_br = Yes(Mut)` and `max_ref_mutbl = Not`, but in my understanding this violation is the same as E0596. check_pat_ident() does returns E0596 by a similar reason [here](https://github.com/rust-lang/rust/blob/fdd1a3b02687817cea41f6bacae3d5fbed2b2cd0/compiler/rustc_hir_typeck/src/pat.rs#L837-L856).
…kingjubilee Rollup of 13 pull requests Successful merges: - rust-lang#134999 (Add cygwin target.) - rust-lang#135439 (Make `-O` mean `OptLevel::Aggressive`) - rust-lang#136397 (Add a comment pointing to ICE-136223) - rust-lang#136681 (resolve `llvm-config` path properly on cross builds) - rust-lang#136686 (Clean up `HashMap` and `HashSet` docs.) - rust-lang#136694 (Update minifier version to `0.3.4`) - rust-lang#136706 (compiler: mostly-finish `rustc_abi` updates) - rust-lang#136710 (Document `Sum::sum` returns additive identities for `[]`) - rust-lang#136724 (Make `AsyncFnOnce`, `AsyncFnMut`, `AsyncFn` non-`#[fundamental]`) - rust-lang#136727 (Have a break from review rotation) - rust-lang#136730 (transmutability: fix ICE when passing wrong ADT to ASSUME) - rust-lang#136736 (Small resolve refactor) - rust-lang#136746 (Emit an error if `-Zdwarf-version=1` is requested) r? `@ghost` `@rustbot` modify labels: rollup
…mutability-cap-violated, r=Nadrieril Add a comment pointing to ICE-136223 Fixes rust-lang#136223 ## Steps how the ICE happen This explanation is based on the test case `&Some(Some(x)) = &Some(&mut Some(0))`. The case should fail with E0596 error, but it catches the debug assertion instead. 1. For the first `&`: In check_pat_ref(), the value max_ref_mutbl becomes MutblCap::Not ([here](https://github.com/rust-lang/rust/blob/fdd1a3b02687817cea41f6bacae3d5fbed2b2cd0/compiler/rustc_hir_typeck/src/pat.rs#L2394-L2396)). Once max_ref_mutbl becomes Not, it will never be back to MutblCap::Mut. 2. For `&mut`: In peel_off_references(), because Some(x) doesn't have `&` nor `&mut`, `&mut` in `&mut Some(0)` is not consumed then default_binding_mode (def_br) becomes `ByRef::Yes(Mutability::Mut)` (around [here](https://github.com/rust-lang/rust/blob/fdd1a3b02687817cea41f6bacae3d5fbed2b2cd0/compiler/rustc_hir_typeck/src/pat.rs#L519-L536)). This will be inherited to the next step. So this pattern has the mismatch between `def_br=Yes(Mut)` and `max_ref_mutbl=Not` now. 3. For the value `0`: Because of the step 2, the default_binding_mode is `Yes(Mut)`, but max_ref_mutbl is `Not` from the step 1. It causes the assertion error [here](https://github.com/rust-lang/rust/blob/fdd1a3b02687817cea41f6bacae3d5fbed2b2cd0/compiler/rustc_hir_typeck/src/pat.rs#L427-L430). ## What this PR fixes Step 1 has happened from [this commit](rust-lang@e2f3ce9) by deleting `no_ref_mut_behind_and` from the if block. In my understanding, after RFC3627 is released, step 1 should happen not only 2024 edition but also other editions to track MutblCap value. But for now, it should not happen for non-2024 edition. So I put it back. NOTE: I think there is another solution - We should return an E0596 error in calc_default_binding_mode() instead of the debug assertion. Since the assertion is caused by the mismatch between `def_br = Yes(Mut)` and `max_ref_mutbl = Not`, but in my understanding this violation is the same as E0596. check_pat_ident() does returns E0596 by a similar reason [here](https://github.com/rust-lang/rust/blob/fdd1a3b02687817cea41f6bacae3d5fbed2b2cd0/compiler/rustc_hir_typeck/src/pat.rs#L837-L856).
…kingjubilee Rollup of 10 pull requests Successful merges: - rust-lang#136397 (Add a comment pointing to ICE-136223) - rust-lang#136681 (resolve `llvm-config` path properly on cross builds) - rust-lang#136686 (Clean up `HashMap` and `HashSet` docs.) - rust-lang#136694 (Update minifier version to `0.3.4`) - rust-lang#136706 (compiler: mostly-finish `rustc_abi` updates) - rust-lang#136710 (Document `Sum::sum` returns additive identities for `[]`) - rust-lang#136724 (Make `AsyncFnOnce`, `AsyncFnMut`, `AsyncFn` non-`#[fundamental]`) - rust-lang#136727 (Have a break from review rotation) - rust-lang#136730 (transmutability: fix ICE when passing wrong ADT to ASSUME) - rust-lang#136736 (Small resolve refactor) r? `@ghost` `@rustbot` modify labels: rollup
…kingjubilee Rollup of 8 pull requests Successful merges: - rust-lang#136397 (Add a comment pointing to ICE-136223) - rust-lang#136686 (Clean up `HashMap` and `HashSet` docs.) - rust-lang#136706 (compiler: mostly-finish `rustc_abi` updates) - rust-lang#136710 (Document `Sum::sum` returns additive identities for `[]`) - rust-lang#136724 (Make `AsyncFnOnce`, `AsyncFnMut`, `AsyncFn` non-`#[fundamental]`) - rust-lang#136727 (Have a break from review rotation) - rust-lang#136730 (transmutability: fix ICE when passing wrong ADT to ASSUME) - rust-lang#136736 (Small resolve refactor) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#136397 - Shunpoco:issue-136223-ICE-pattern-mutability-cap-violated, r=Nadrieril Add a comment pointing to ICE-136223 Fixes rust-lang#136223 ## Steps how the ICE happen This explanation is based on the test case `&Some(Some(x)) = &Some(&mut Some(0))`. The case should fail with E0596 error, but it catches the debug assertion instead. 1. For the first `&`: In check_pat_ref(), the value max_ref_mutbl becomes MutblCap::Not ([here](https://github.com/rust-lang/rust/blob/fdd1a3b02687817cea41f6bacae3d5fbed2b2cd0/compiler/rustc_hir_typeck/src/pat.rs#L2394-L2396)). Once max_ref_mutbl becomes Not, it will never be back to MutblCap::Mut. 2. For `&mut`: In peel_off_references(), because Some(x) doesn't have `&` nor `&mut`, `&mut` in `&mut Some(0)` is not consumed then default_binding_mode (def_br) becomes `ByRef::Yes(Mutability::Mut)` (around [here](https://github.com/rust-lang/rust/blob/fdd1a3b02687817cea41f6bacae3d5fbed2b2cd0/compiler/rustc_hir_typeck/src/pat.rs#L519-L536)). This will be inherited to the next step. So this pattern has the mismatch between `def_br=Yes(Mut)` and `max_ref_mutbl=Not` now. 3. For the value `0`: Because of the step 2, the default_binding_mode is `Yes(Mut)`, but max_ref_mutbl is `Not` from the step 1. It causes the assertion error [here](https://github.com/rust-lang/rust/blob/fdd1a3b02687817cea41f6bacae3d5fbed2b2cd0/compiler/rustc_hir_typeck/src/pat.rs#L427-L430). ## What this PR fixes Step 1 has happened from [this commit](rust-lang@e2f3ce9) by deleting `no_ref_mut_behind_and` from the if block. In my understanding, after RFC3627 is released, step 1 should happen not only 2024 edition but also other editions to track MutblCap value. But for now, it should not happen for non-2024 edition. So I put it back. NOTE: I think there is another solution - We should return an E0596 error in calc_default_binding_mode() instead of the debug assertion. Since the assertion is caused by the mismatch between `def_br = Yes(Mut)` and `max_ref_mutbl = Not`, but in my understanding this violation is the same as E0596. check_pat_ident() does returns E0596 by a similar reason [here](https://github.com/rust-lang/rust/blob/fdd1a3b02687817cea41f6bacae3d5fbed2b2cd0/compiler/rustc_hir_typeck/src/pat.rs#L837-L856).
Fixes #136223
Steps how the ICE happen
This explanation is based on the test case
&Some(Some(x)) = &Some(&mut Some(0))
.The case should fail with E0596 error, but it catches the debug assertion instead.
&
: In check_pat_ref(), the value max_ref_mutbl becomes MutblCap::Not (here). Once max_ref_mutbl becomes Not, it will never be back to MutblCap::Mut.&mut
: In peel_off_references(), because Some(x) doesn't have&
nor&mut
,&mut
in&mut Some(0)
is not consumed then default_binding_mode (def_br) becomesByRef::Yes(Mutability::Mut)
(around here). This will be inherited to the next step. So this pattern has the mismatch betweendef_br=Yes(Mut)
andmax_ref_mutbl=Not
now.0
: Because of the step 2, the default_binding_mode isYes(Mut)
, but max_ref_mutbl isNot
from the step 1. It causes the assertion error here.What this PR fixes
Step 1 has happened from this commit by deleting
no_ref_mut_behind_and
from the if block. In my understanding, after RFC3627 is released, step 1 should happen not only 2024 edition but also other editions to track MutblCap value. But for now, it should not happen for non-2024 edition. So I put it back.NOTE: I think there is another solution - We should return an E0596 error in calc_default_binding_mode() instead of the debug assertion. Since the assertion is caused by the mismatch between
def_br = Yes(Mut)
andmax_ref_mutbl = Not
, but in my understanding this violation is the same as E0596. check_pat_ident() does returns E0596 by a similar reason here.