ICE: Unexpected type for 'Single' constructor
#117100
Labels
A-exhaustiveness-checking
Relating to exhaustiveness / usefulness checking of patterns
A-patterns
Relating to patterns and pattern matching
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
matthiaskrgr
added
I-ICE
rustbot
added
the
needs-triage
|
cc @Nadrieril probably ^^ |
|
Out of curiosity, how do you get these? Do you regularly run the whole rustc test suite with some lints turned on? |
I usually do that about daily 😉 :D |
|
Wow :D Stunning work |
Noratrieb
added
A-patterns
Nadrieril
added
the
A-exhaustiveness-checking
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Dec 22, 2023
…-errors
Exhaustiveness: reveal opaque types properly
Previously, exhaustiveness had no clear policy around opaque types. In this PR I propose the following policy: within the body of an item that defines the hidden type of some opaque type, exhaustiveness checking on a value of that opaque type is performed using the concrete hidden type inferred in this body.
I'm not sure how consistent this is with other operations allowed on opaque types; I believe this will require FCP.
From what I can tell, this doesn't change anything for non-empty types.
The observable changes are:
- when the real type is uninhabited, matches within the defining scopes can now rely on that for exhaustiveness, e.g.:
```rust
#[derive(Copy, Clone)]
enum Void {}
fn return_never_rpit(x: Void) -> impl Copy {
if false {
match return_never_rpit(x) {}
}
x
}
```
- this properly fixes ICEs like rust-lang#117100 that occurred because a same match could have some patterns where the type is revealed and some where it is not.
Bonus subtle point: if `x` is opaque, a match like `match x { ("", "") => {} ... }` will constrain its type ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=901d715330eac40339b4016ac566d6c3)). This is not the case for `match x {}`: this will not constain the type, and will only compile if something else constrains the type to be empty.
Fixes rust-lang#117100
r? `@oli-obk`
Edited for precision of the wording
[Included](rust-lang#116821 (comment)) in the FCP on this PR is this rule:
> Within the body of an item that defines the hidden type of some opaque type, exhaustiveness checking on a value of that opaque type is performed using the concrete hidden type inferred in this body.
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this issue
Dec 24, 2023
Exhaustiveness: reveal opaque types properly
Previously, exhaustiveness had no clear policy around opaque types. In this PR I propose the following policy: within the body of an item that defines the hidden type of some opaque type, exhaustiveness checking on a value of that opaque type is performed using the concrete hidden type inferred in this body.
I'm not sure how consistent this is with other operations allowed on opaque types; I believe this will require FCP.
From what I can tell, this doesn't change anything for non-empty types.
The observable changes are:
- when the real type is uninhabited, matches within the defining scopes can now rely on that for exhaustiveness, e.g.:
```rust
#[derive(Copy, Clone)]
enum Void {}
fn return_never_rpit(x: Void) -> impl Copy {
if false {
match return_never_rpit(x) {}
}
x
}
```
- this properly fixes ICEs like rust-lang/rust#117100 that occurred because a same match could have some patterns where the type is revealed and some where it is not.
Bonus subtle point: if `x` is opaque, a match like `match x { ("", "") => {} ... }` will constrain its type ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=901d715330eac40339b4016ac566d6c3)). This is not the case for `match x {}`: this will not constain the type, and will only compile if something else constrains the type to be empty.
Fixes rust-lang/rust#117100
r? `@oli-obk`
Edited for precision of the wording
[Included](rust-lang/rust#116821 (comment)) in the FCP on this PR is this rule:
> Within the body of an item that defines the hidden type of some opaque type, exhaustiveness checking on a value of that opaque type is performed using the concrete hidden type inferred in this body.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
File: /tmp/icemaker/81DF126D24557409A8EFD18AB1CCB3D2E8119C89297C34BA28DE025833020886.rs
auto-reduced (treereduce-rust):
original code
original:
Version information
Command:
/home/matthias/.rustup/toolchains/master/bin/rustc -Zcrate-attr=feature(non_exhaustive_omitted_patterns_lint) -Wnon-exhaustive-omitted-patternsProgram output
The text was updated successfully, but these errors were encountered: