-
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
ICE: Unexpected type for constructor Variant(1)
#125888
Comments
My thought after some debug: Consider two programs below: // program A
enum NestedEnum {
First,
Second,
}
enum Enum {
Variant(*const ()),
// Variant(*const &'a ()),
}
fn foo(x: Enum) {
match x {
Enum::Variant(NestedEnum::Second) => {}
}
} // program B
enum NestedEnum {
First,
Second,
}
enum Enum {
// Variant(*const ()),
Variant(*const &'a ()),
}
fn foo(x: Enum) {
match x {
Enum::Variant(NestedEnum::Second) => {}
}
} program B will panic at compile while program A not. The difference occurs here: rust/compiler/rustc_mir_build/src/thir/pattern/check_match.rs Lines 29 to 32 in 6a207f4
program A will early return at tcx.thir_body(def_id)? , but program B will not and cause the panic.I have checked the typeck_results of two programs, and there is a key different between them: in program A typeck_results.tainted_by_errors is Some(ErrorGuaranteed(())) , and in program B that is None .
A:
B:
In |
Because this hack, I think. rust/compiler/rustc_hir_typeck/src/writeback.rs Lines 125 to 130 in 76c7382
|
program A set rust/compiler/rustc_hir_typeck/src/pat.rs Line 1165 in 921645c
|
Avoid follow-up errors and ICEs after missing lifetime errors on data structures Tuple struct constructors are functions, so when we call them typeck will use the signature tuple struct constructor function to provide type hints. Since typeck mostly ignores and erases lifetimes, we end up never seeing the error lifetime in writeback, thus not tainting the typeck result. Now, we eagerly taint typeck results by tainting from `resolve_vars_if_possible`, which is called all over the place. I did not carry over all the `crashes` test suite tests, as they are really all the same cause (missing or unknown lifetime names in tuple struct definitions or generic arg lists). fixes rust-lang#124262 fixes rust-lang#124083 fixes rust-lang#125155 fixes rust-lang#125888 fixes rust-lang#125992 fixes rust-lang#126666 fixes rust-lang#126648 fixes rust-lang#127268
…ler-errors Avoid follow-up errors and ICEs after missing lifetime errors on data structures Tuple struct constructors are functions, so when we call them typeck will use the signature tuple struct constructor function to provide type hints. Since typeck mostly ignores and erases lifetimes, we end up never seeing the error lifetime in writeback, thus not tainting the typeck result. Now, we eagerly taint typeck results by tainting from `resolve_vars_if_possible`, which is called all over the place. I did not carry over all the `crashes` test suite tests, as they are really all the same cause (missing or unknown lifetime names in tuple struct definitions or generic arg lists). fixes rust-lang#124262 fixes rust-lang#124083 fixes rust-lang#125155 fixes rust-lang#125888 fixes rust-lang#125992 fixes rust-lang#126666 fixes rust-lang#126648 fixes rust-lang#127268
I try to reduce the code of #125155 and find the ice changed.
Maybe duplicated with #120601 and #124004, but I think the code here is cleaner.
Code
Meta
rustc --version --verbose
:Error output
The text was updated successfully, but these errors were encountered: