-
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
TAIT: "unconstrained opaque type" error even if it's constrained #96572
Comments
UPDATE: the below ICE is fixed now! I don't think we can really allow this. No pattern but a straight up binding is a valid pattern for an opaque type. If you actually give that pattern a type #![feature(type_alias_impl_trait)]
fn main() {
type T = impl Copy;
let foo: T = (1u32, 2u32);
let (a, b): (u32, u32) = foo;
} then we get a lot of ICEs from borrowck. The interesting ones are
These happen because we assume that if a pattern type checks, that we can actually destructure the thing that was moved into the pattern. Unfortunately for opaque types that isn't true. I guess the simple solution would be to just forbid it. We could try to allow it, but I'm not sure how to do that in general without just throwing more logic into match checking and mir building. Just patching the type of |
…Simulacrum Add regression and bug tests this tracks the behaviour from rust-lang#96572 in our test suite
UPDATE: the below ICE is fixed now! Other examples: #![feature(type_alias_impl_trait)]
fn main() {
type T = impl Copy;
let foo: T = (1u32, 2u32);
match foo {
(a, b) => (),
}
} also gives an error (playground) |
Also ICEs (playground): #![feature(type_alias_impl_trait)]
fn main() {
type T = impl Copy;
let foo: T = Some((1u32, 2u32));
match foo {
None => (),
Some((a, b)) => (),
}
} |
triage: Implement a "opaque type downcast projection" in mir and insert appropriately |
Triage: #96572 (comment) and #96572 (comment) are fixed by #96515. The last one (#96572 (comment)) is still ICE. |
Fun: these can all be triggered on stable, too: #[allow(unconditional_recursion)]
fn foo(b: bool) -> impl Copy {
let (mut x, mut y) = foo(false);
x = 42;
y = "foo";
if b {
panic!()
} else {
foo(true)
}
} and fn foo(b: bool) -> Option<impl Copy> {
if b {
return None;
}
match foo(!b) {
Some((mut x, mut y)) => {
x = 42;
y = "foo";
}
None => {}
}
None
} |
…estebank Allow patterns to constrain the hidden type of opaque types fixes rust-lang#96572 reverts a revert as original PR was a perf regression that was fixed by reverting it: rust-lang#99368 (comment)) TODO: * check if rust-lang#99685 is avoided
…estebank Allow patterns to constrain the hidden type of opaque types fixes rust-lang#96572 reverts a revert as original PR was a perf regression that was fixed by reverting it: rust-lang#99368 (comment)) TODO: * check if rust-lang#99685 is avoided
This is allowed:
But this isn't:
It seems strange to me that adding code causes a type that was previously properly constrained to not longer be so. I'm not sure if it's a diagnostics issue, or if it should indeed be allowed...
See playground
rustc 1.62.0-nightly (a707f40 2022-04-29)
@rustbot label A-impl-trait F-type_alias_impl_trait
The text was updated successfully, but these errors were encountered: