-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
ICE when matching with an opaque constant pattern #78071
Labels
A-exhaustiveness-checking
Relating to exhaustiveness / usefulness checking of patterns
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
Nadrieril
added
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
labels
Oct 18, 2020
@rustbot modify labels: +A-exhaustiveness-checking |
rustbot
added
the
A-exhaustiveness-checking
Relating to exhaustiveness / usefulness checking of patterns
label
Oct 18, 2020
This was referenced Oct 18, 2020
I'll self-assign while I investigate but I don't know if I can fix it alone yet. |
This was an error back in 1.25,
But has been an ICE since as fast back as 1.26. |
Thanks for the investigation! |
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this issue
Oct 22, 2020
…, r=varkor Cleanup constant matching in exhaustiveness checking This supercedes rust-lang#77390. I made the `Opaque` constructor work. I have opened two issues rust-lang#78071 and rust-lang#78057 from the discussion we had on the previous PR. They are not regressions nor directly related to the current PR so I thought we'd deal with them separately. I left a FIXME somewhere because I didn't know how to compare string constants for equality. There might even be some unicode things that need to happen there. In the meantime I preserved previous behavior. EDIT: I accidentally fixed rust-lang#78071
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this issue
Oct 22, 2020
…, r=varkor Cleanup constant matching in exhaustiveness checking This supercedes rust-lang#77390. I made the `Opaque` constructor work. I have opened two issues rust-lang#78071 and rust-lang#78057 from the discussion we had on the previous PR. They are not regressions nor directly related to the current PR so I thought we'd deal with them separately. I left a FIXME somewhere because I didn't know how to compare string constants for equality. There might even be some unicode things that need to happen there. In the meantime I preserved previous behavior. EDIT: I accidentally fixed rust-lang#78071
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-exhaustiveness-checking
Relating to exhaustiveness / usefulness checking of patterns
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Code
playground
This ICEs on stable and nightly. Interestingly, if the type derives
Eq
this doesn't fail on nightly anymore, but still on stable. The change surely has something to do with the recent change in expansion of constant patterns (#70743).Note also that this doesn't ICE with 0 or 1 references.
From the error, this is due to an invariant being broken in
thir/pattern/_match.rs
. This is likely to be due dospecialize_one_pattern
returning the wrong number of fields after specialization. So it's the interaction ofconst_to_pat.rs
constant expansion and_match.rs
pattern specialization that does something weird. I'm currently baffled as to why this happens.Error output
Backtrace
The text was updated successfully, but these errors were encountered: