-
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
the type of ProjectionElem::Field
is not correct wrt subtyping
#96514
Comments
@rustbot claim intend to work on this myself |
also add a test for struct Foo<T>(T); // `T` is covariant.
fn foo<'b>(x: Foo<Foo<for<'a> fn(&'a ())>>) {
let Foo(Foo(y)): Foo<Foo<fn(&'b ())>> = x;
} |
correctly deal with user type ascriptions in pat supersedes rust-lang#93856 `thir::PatKind::AscribeUserType` previously resulted in `CanonicalUserTypeAnnotations` where the inferred type already had a subtyping relation according to `variance` to the `user_ty`. The bug can pretty much be summarized as follows: - during mir building - `user_ty -> inferred_ty`: considers variance - `StatementKind::AscribeUserType`: `inferred_ty` is the type of the place, so no variance needed - during mir borrowck - `user_ty -> inferred_ty`: does not consider variance - `StatementKind::AscribeUserType`: applies variance This mostly worked fine. The lifetimes in `inferred_ty` were only bound by its relation to `user_ty` and to the `place` of `StatementKind::AscribeUserType`, so it doesn't matter where exactly the subtyping happens. It does however matter when having higher ranked subtying. At this point the place where the subtyping happens is forced, causing this mismatch between building and borrowck to result in unintended errors. cc rust-lang#96514 which is pretty much the same issue r? `@nikomatsakis`
That's imo the correct solution. Open to mentor someone here, ideally with some experience with working with If you're interested and need help, contact me on zulip and we can either chat about it there or on zoom. |
@rustbot claim |
Revert rust-lang#103880 "Use non-ascribed type as field's type in mir" This PR prepares a revert for rust-lang#103880 to fix rust-lang#105809, rust-lang#105881, rust-lang#105886 and others (like the duplicates of the first one), in case an actual fix can't get done today. I've also added the MCVE from rust-lang#105809. There is no MCVE for the rust-lang#105881 and rust-lang#105886 ICEs yet however, so there are no tests for them here, although we'll need one before relanding the original changes. Were this PR to land, it would also reopen rust-lang#96514 as it was fixed by the original PR. Opening as draft to allow time for a possible fix. r? `@jackh726`
This needs a reopen since 696563e landed. |
Reopening, as I don't think @RalfJung expected to close this with the rust-lang/miri#2738 miri rustup. |
Yeah that was some rustc commit with a "Fixes #96514" in it being mirrored. This might happen a few more times, since github will re-execute these commit commands when commits move around repositories. |
Use covariance on type relations of field projection types if possible It's fine to use covariance here unless we're in a mutating context. Fixes rust-lang/rust#96514 Supersedes rust-lang/rust#105958 r? `@lcnr`
Use non-ascribed type as field's type in mir Fixes rust-lang/rust#96514 r? `@lcnr`
Use covariance on type relations of field projection types if possible It's fine to use covariance here unless we're in a mutating context. Fixes rust-lang/rust#96514 Supersedes rust-lang/rust#105958 r? `@lcnr`
Use non-ascribed type as field's type in mir Fixes rust-lang/rust#96514 r? `@lcnr`
Use covariance on type relations of field projection types if possible It's fine to use covariance here unless we're in a mutating context. Fixes rust-lang/rust#96514 Supersedes rust-lang/rust#105958 r? `@lcnr`
should compile but errors with
looking at the mir of
foo
it becomes clear why that happens:notice that in
_2 = (_1.0: fn(&()));
the type of_1.0
is actuallyfor<'a> fn(&'a ())
.Possible ways to fix this are:
always lazily recompute the type of the field instead of storing it in the mirThe text was updated successfully, but these errors were encountered: