-
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
fix(generic_const_exprs): Fix predicate inheritance for children of opaque types #99801
fix(generic_const_exprs): Fix predicate inheritance for children of opaque types #99801
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @compiler-errors (or someone else) soon. Please see the contribution instructions for more information. |
r? @BoxyUwU |
@rustbot label +A-const-generics +F-generic_const_exprs |
I suspect this probably doesnt work right for |
I think this will get resolved by @spastorino's work which removes this parent generics behaviour of return position impl trait. This PR is just more proof that doing that is important. It feels like a band-aid that I would prefer not to merge |
@oli-obk Sure, I'm OK with closing this for now and wait for the RPIT refactor to happen. Do you have a pointer to where that is happening & the timeline? Just want to get this bug properly documented here so that other people don't end up wasting time on this. |
I don't know where @spastorino is tracking this work. I'll let him post a link in case there's a hackmd. We could link #99705 from the |
Ok sounds good. Let's keep this PR open in the mean time so that those who need this now can use the branch as a custom toolchain. |
For some reason I've missed this one. Anyway, my changes are close to be completed. Right now I'm fixing some bugs on my branch. |
PR with RPIT changes is now up #101345, we still need to address some problems that crater have found. |
☔ The latest upstream changes (presumably #102306) made this pull request unmergeable. Please resolve the merge conflicts. |
discussed in T-compiler triage meeting. reassigning ownership for design decisions here to T-types. @rustbot label: -T-compiler +T-types |
I think we should "just do this PR" and remove the changes when we'll actually change the opaque type parenting logic. So... after much work that didn't get merged after all, @Neo-Zhixing can you rebase this PR, we can then merge it. |
@oli-obk changes merged with master. Thanks! |
@Neo-Zhixing we don't actually allow merge conflicts in the rust repo: https://rustc-dev-guide.rust-lang.org/git.html#no-merge-policy Can you rebase this commit instead? |
25a0dd5
to
ccd9e07
Compare
My apologies, I thought GitHub would be able to squash those commits for you. |
@bors r+ |
📌 Commit ccd9e07281b43567de28ad9f6601c49464e44bd6 has been approved by It is now in the queue for this repository. |
did we test if #![feature(generic_const_exprs)]
trait Foo {
type Assoc;
}
trait Bar<const N: usize> {}
impl Foo for () {
type Assoc = ();
}
impl<const N: usize> Bar<N> for () {}
trait Trait {
const ASSOC: usize;
}
fn foo<T: Trait>() -> impl Foo<Assoc = impl Bar<{ T::ASSOC }>> {} |
@bors r- let's add the test, but I think it should work |
a553575
to
744fa61
Compare
@bors r+ |
Is there no way to get nested opaque items in current rustc 🤔 that was what i was going for with |
yes there is. Your example does indeed show that, but it's not an issue because the inner opaque item fetches the predicates of the outer one, which fetches it from the function. |
I thought the bug was that opaque type items dont have all the predicates of the parent, so anon consts inheriting predicates from the opaque is incorrect since they should have "all" of them. Clearly i've misunderstood something here since if that was true the anon const having a parent of the outter opaque type would not be correct 😅 |
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#99801 (fix(generic_const_exprs): Fix predicate inheritance for children of opaque types) - rust-lang#103610 (Allow use of `-Clto=thin` with `-Ccodegen-units=1` in general) - rust-lang#103870 (Fix `inferred_kind` ICE) - rust-lang#103875 (Simplify astconv item def id handling) - rust-lang#103886 (rustdoc: Fix merge of attributes for reexports of local items) - rust-lang#103890 (rustdoc: remove unused mobile CSS `.rustdoc { padding-top: 0 }`) Failed merges: - rust-lang#103884 (Add visit_fn_ret_ty to hir intravisit) r? `@ghost` `@rustbot` modify labels: rollup
…-ct, r=BoxyUwU Resolve anon const's parent predicates to direct parent instead of opaque's parent When an anon const is inside of an opaque, rust-lang#99801 added a hack to resolve the anon const's parent predicates *not* to the opaque's predicates, but to the opaque's *parent's* predicates. This is insufficient when considering nested opaques. This means that the `predicates_of` an anon const might reference duplicated lifetimes (installed by `compute_bidirectional_outlives_predicates`) when computing known outlives in MIR borrowck, leading to these ICEs: Fixes rust-lang#121574 Fixes rust-lang#118403 ~~Instead, we should be using the `OpaqueTypeOrigin` to acquire the owner item (fn/type alias/etc) of the opaque, whose predicates we're fine to mention.~~ ~~I think it's a bit sketchy that we're doing this at all, tbh; I think it *should* be fine for the anon const to inherit the predicates of the opaque it's located inside. However, that would also mean that we need to make sure the `generics_of` that anon const line up in the same way.~~ ~~None of this is important to solve right now; I just want to fix these ICEs so we can land rust-lang#125468, which accidentally fixes these issues in a different and unrelated way.~~ edit: We don't need this special case anyways because we install the right parent item in `generics_of` anyways: https://github.com/rust-lang/rust/blob/213ad10c8f0fc275648552366275dc4e07f97462/compiler/rustc_hir_analysis/src/collect/generics_of.rs#L150 r? `@BoxyUwU`
Rollup merge of rust-lang#125501 - compiler-errors:opaque-opaque-anon-ct, r=BoxyUwU Resolve anon const's parent predicates to direct parent instead of opaque's parent When an anon const is inside of an opaque, rust-lang#99801 added a hack to resolve the anon const's parent predicates *not* to the opaque's predicates, but to the opaque's *parent's* predicates. This is insufficient when considering nested opaques. This means that the `predicates_of` an anon const might reference duplicated lifetimes (installed by `compute_bidirectional_outlives_predicates`) when computing known outlives in MIR borrowck, leading to these ICEs: Fixes rust-lang#121574 Fixes rust-lang#118403 ~~Instead, we should be using the `OpaqueTypeOrigin` to acquire the owner item (fn/type alias/etc) of the opaque, whose predicates we're fine to mention.~~ ~~I think it's a bit sketchy that we're doing this at all, tbh; I think it *should* be fine for the anon const to inherit the predicates of the opaque it's located inside. However, that would also mean that we need to make sure the `generics_of` that anon const line up in the same way.~~ ~~None of this is important to solve right now; I just want to fix these ICEs so we can land rust-lang#125468, which accidentally fixes these issues in a different and unrelated way.~~ edit: We don't need this special case anyways because we install the right parent item in `generics_of` anyways: https://github.com/rust-lang/rust/blob/213ad10c8f0fc275648552366275dc4e07f97462/compiler/rustc_hir_analysis/src/collect/generics_of.rs#L150 r? `@BoxyUwU`
Fixes #99705
We currently have a special case to perform predicate inheritance when the const item is in the generics. I think we're also going to need this for opaque return types. When evaluating the predicates applied to the associated item, it'll inherit from its parent, the opaque type, which will never have predicates applied. This PR bypass the opaque typed parent and inherit predicates directly from the function itself.