-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
TAIT: empty match on TAIT confuses typeck #117413
Comments
I think in the second example mir building doesn't generate code for the trailing expression because it's statically known as dead code. But I thought we were keeping around the typeck types nowadays, and typeck should be the same for both functions |
I don't think that's it, same error if I put the match in a branch (updated playground link with more variations): type X = impl Copy;
//~^ ERROR unconstrained opaque type
fn empty_opaque(x: super::Void) -> X {
if false {
match empty_opaque(x) {}
//~^ ERROR non-empty
}
x
} |
In fact this doesn't need an empty type at all: type X = impl Copy;
//~^ ERROR unconstrained opaque type
fn empty_opaque() -> X {
if false {
match empty_opaque() {}
//~^ ERROR non-empty
}
0u8
} |
I think we're generating bogus MIR or THIR because of that empty match --
Are you sure the bug doesn't exist on the THIR/MIR building side, @Nadrieril? (hacked |
Oh I'm sure of nothing 😄 I just assumed an unreachable in a |
So: rust/compiler/rustc_mir_build/src/build/mod.rs Lines 58 to 60 in e6e931d
If there's a match error, we end up constructing a failure MIR body. This will prevent us from inferring the opaque later on. Let me see if I can cook up a quick fix. |
…r=oli-obk Also consider TAIT to be uncomputable if the MIR body is tainted Not totally sure if this is the best solution. We could, alternatively, look at the hir typeck results and try to take a type from there instead of just falling back to type error, inferring `u8` instead of `{type error}`. Not certain it really matters, though. Happy to iterate on this. Fixes rust-lang#117413 r? `@oli-obk` cc `@Nadrieril`
… r=oli-obk Build a better MIR body when errors are encountered Doesn't really have much of an effect on its own, but it does lead to a less confusing phony MIR body being generated when an error is detected during THIR/MIR/match building. This was quite confusing when I hacked `-Zunpretty=mir` to emit `mir_built` rather than `instance_mir`. This coincidentually also fixes rust-lang#117413, but not as generally as rust-lang#117416. cc `@Nadrieril`
Rollup merge of rust-lang#117416 - compiler-errors:tait-in-bad-body, r=oli-obk Also consider TAIT to be uncomputable if the MIR body is tainted Not totally sure if this is the best solution. We could, alternatively, look at the hir typeck results and try to take a type from there instead of just falling back to type error, inferring `u8` instead of `{type error}`. Not certain it really matters, though. Happy to iterate on this. Fixes rust-lang#117413 r? ``@oli-obk`` cc ``@Nadrieril``
…=oli-obk Build a better MIR body when errors are encountered Doesn't really have much of an effect on its own, but it does lead to a less confusing phony MIR body being generated when an error is detected during THIR/MIR/match building. This was quite confusing when I hacked `-Zunpretty=mir` to emit `mir_built` rather than `instance_mir`. This coincidentually also fixes rust-lang#117413, but not as generally as rust-lang#117416. cc `@Nadrieril`
I tried this code (playground):
Somehow in the second case we think that
X
is unconstrained even though it doesn't seem to contain more or less type information than the first case. Note also that this does not error if I use RPIT instead.The text was updated successfully, but these errors were encountered: