Collect relevant item bounds from trait clauses for nested rigid projections #120752

compiler-errors · 2024-02-07T20:46:13Z

Rust currently considers trait where-clauses that bound the trait's own associated types to act like an item bound:

trait Foo where Self::Assoc: Bar { type Assoc; }
// acts as if:
trait Foo { type Assoc: Bar; }

Background

This behavior has existed since essentially forever (i.e. before Rust 1.0), since we originally started out by literally looking at the where clauses written on the trait when assembling SelectionCandidate::ProjectionCandidate for projections. However, looking at the predicates of the associated type themselves was not sound, since it was unclear which predicates were assumed and which predicates were implied, and therefore this was reworked in #72788 (which added a query for the predicates we consider for ProjectionCandidates), and then finally item bounds and predicates were split in #73905.

Problem 1: GATs don't uplift bounds correctly

All the while, we've still had logic to uplift associated type bounds from a trait's where clauses. However, with the introduction of GATs, this logic was never really generalized correctly for them, since we were using simple equality to test if the self type of a trait where clause is a projection. This leads to shortcomings, such as:

trait Foo
where
    for<'a> Self::Gat<'a>: Debug,
{
    type Gat<'a>;
}

fn test<T: Foo>(x: T::Gat<'static>) {
    //~^ ERROR `<T as Foo>::Gat<'a>` doesn't implement `Debug`
    println!("{:?}", x);
}

Problem 2: Nested associated type bounds are not uplifted

We also don't attempt to uplift bounds on nested associated types, something that we couldn't really support until #120584. This can be demonstrated best with an example:

trait A
    where Self::Assoc: B,
    where <Self::Assoc as B>::Assoc2: C,
{
    type Assoc; // <~ The compiler *should* treat this like it has an item bound `B<Assoc2: C>`.
}

trait B { type Assoc2; }
trait C {}

fn is_c<T: C>() {}

fn test<T: A>() {
    is_c::<<Self::Assoc as B>::Assoc2>();
    //~^ ERROR the trait bound `<<T as A>::Assoc as B>::Assoc2: C` is not satisfied
}

Why does this matter?

Well, generalizing this behavior bridges a gap between the associated type bounds (ATB) feature and trait where clauses. Currently, all bounds that can be stably written on associated types can also be expressed as where clauses on traits; however, with the stabilization of ATB, there are now bounds that can't be desugared in the same way. This fixes that.

How does this PR fix things?

First, when scraping item bounds from the trait's where clauses, given a trait predicate, we'll loop of the self type of the predicate as long as it's a projection. If we find a projection whose trait ref matches, we'll uplift the bound. This allows us to uplift, for example <Self as Trait>::Assoc: Bound (pre-existing), but also <<Self as Trait>::Assoc as Iterator>::Item: Bound (new).

If that projection is a GAT, we will check if all of the GAT's own args are all unique late-bound vars. We then map the late-bound vars to early-bound vars from the GAT -- this allows us to uplift for<'a, 'b> Self::Assoc<'a, 'b>: Trait into an item bound, but we will leave for<'a> Self::Assoc<'a, 'a>: Trait and Self::Assoc<'static, 'static>: Trait alone.

Okay, but does this really matter?

I consider this to be an improvement of the status quo because it makes GATs a bit less magical, and makes rigid projections a bit more expressive.

lcnr · 2024-02-08T08:44:05Z

r=me after fcp

though after this PR, associated type bounds are always just a desugaring of otherwise writeable where-clauses on the trait, are they?

compiler-errors · 2024-03-02T18:50:57Z

though after this PR, associated type bounds are always just a desugaring of otherwise writeable where-clauses on the trait, are they?

So not exactly. We don't currently uplift associated types for GATs properly, e.g.

trait Foo where Self::Assoc<'a>: Iterator<Item = &'a ()> { type Assoc<'a>; }

IDK if we should. Currently that code even errors with E0582:

error[E0582]: binding for associated type `Item` references lifetime `'a`, which does not appear in the trait input types

lcnr · 2024-03-04T10:33:26Z

I feel like the following should compile: 'a is a higher-ranked region and constrained by the GAT. I would like that bound to also get hoisted to the item_bounds but idk how difficult this is to implemented.

trait Foo where for<'a> Self::Assoc<'a>: Iterator<Item = &'a ()> { type Assoc<'a>; }

compiler-errors · 2024-03-04T15:07:15Z

I would like that bound to also get hoisted to the item_bounds but idk how difficult this is to implemented.

Shouldn't be too hard, just need to map them to their early-bound indices.

feel like the following should compile: 'a is a higher-ranked region and constrained by the GAT.

IDK much about the motivation behind E0582.

…ections, GATs

compiler-errors · 2024-03-05T17:56:43Z

Ok this is ready for a review at least :>

lcnr

please add a test where a GAT is inside of another projection, for<'a, 'b> <<Self::Gat<'a> as Bound>::OtherGat<'b> or sth

lcnr · 2024-03-05T18:06:16Z

compiler/rustc_hir_analysis/src/collect/item_bounds.rs

+            let gat_vars = loop {
+                if let ty::Alias(ty::Projection, alias_ty) = *clause_ty.kind() {
+                    if alias_ty.trait_ref(tcx) == item_trait_ref {
+                        break &alias_ty.args[item_trait_ref.args.len()..];
+                    } else {
+                        clause_ty = alias_ty.self_ty();
+                        continue;
+                    }
+                }
+
+                return None;
+            };
+            // Special-case: No GAT vars, no mapping needed.
+            if gat_vars.is_empty() {
+                return Some((pred, span));
+            }
+
+            // First, check that all of the GAT args are substituted with a unique late-bound arg.
+            // If we find a duplicate, then it can't be mapped to the definition's params.
+            let mut mapping = FxIndexMap::default();
+            let generics = tcx.generics_of(assoc_item_def_id);
+            for (param, var) in std::iter::zip(&generics.params, gat_vars) {
+                let existing = match var.unpack() {
+                    ty::GenericArgKind::Lifetime(re) => {
+                        if let ty::RegionKind::ReBound(ty::INNERMOST, bv) = re.kind() {
+                            mapping.insert(bv.var, tcx.mk_param_from_def(param))
+                        } else {
+                            return None;
+                        }
+                    }
+                    ty::GenericArgKind::Type(ty) => {
+                        if let ty::Bound(ty::INNERMOST, bv) = *ty.kind() {
+                            mapping.insert(bv.var, tcx.mk_param_from_def(param))
+                        } else {
+                            return None;
+                        }
+                    }
+                    ty::GenericArgKind::Const(ct) => {
+                        if let ty::ConstKind::Bound(ty::INNERMOST, bv) = ct.kind() {
+                            mapping.insert(bv, tcx.mk_param_from_def(param))
+                        } else {
+                            return None;
+                        }
+                    }
+                };
+
+                if existing.is_some() {
+                    return None;
+                }
+            }
+
+            // Finally, map all of the args in the GAT to the params we expect, and compress
+            // the remaining late-bound vars so that they count up from var 0.
+            let mut folder = MapAndCompressBoundVars {
+                tcx,
+                binder: ty::INNERMOST,
+                still_bound_vars: vec![],
+                mapping,
+            };
+            let pred = pred.kind().skip_binder().fold_with(&mut folder);


can you move mapping the vars to the gat into a separate function using the above comment?

lcnr · 2024-03-05T18:10:57Z

compiler/rustc_hir_analysis/src/collect/item_bounds.rs

@@ -52,6 +139,117 @@ fn associated_type_bounds<'tcx>(
    all_bounds
 }

+struct MapAndCompressBoundVars<'tcx> {


can you add a doc comment here with an example, e.g.

for<'b, 'c> <Self as Trait<'param>>::Gat<'b>: Bound<'c> results in the mapping 'b to 'gat_param

this folder then converts this to for<'c> <Self as Trait<'param>>::Gat<'gat_param>: Bound<'c>

lcnr · 2024-03-05T18:13:44Z

If I am not wrong, this PR ends up causing associated type bounds to be a simple desugaring. This seems valuable as they can be ignored when explaining the language.

I also think that uplifting gat where-bounds to item bounds is very clearly desirable and doing so for nested also seems like an improvement, even if it likely only infrequently used.

With this

@rfcbot fcp merge

rfcbot · 2024-03-05T18:13:47Z

Team member @lcnr has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

compiler-errors · 2024-03-05T18:18:27Z

If I am not wrong, this PR ends up causing associated type bounds to be a simple desugaring. This seems valuable as they can be ignored when explaining the language.

It's a simple desugaring in where clauses, APIT, and in associated type's item bounds. The only place it remains not a simple deusgaring is for opaques, i.e. impl Iterator<Item: Bound> remains unexpressible with surface Rust w/o ATB. Kind of a shame that that remains unexpressible, but I'd rather not block this on that.

lcnr · 2024-03-05T18:34:04Z

What's the meaming of impl Iterator<Item: Bound>. It is not impl Iterator<Item = impl Bound>, but instead existential type RPIT: Iterator where Self::Item: Bound;? For RPIT, is there an observable difference between using an nested opaque and using an (currently not otherwise expressable) item bound?

compiler-errors · 2024-03-05T18:38:48Z

It is not impl Iterator<Item = impl Bound>, but instead existential type RPIT: Iterator where Self::Item: Bound;?

Yes; this was what #120584 achieved by always lowering associated type bounds as bounds and never as nested RPITs.

is there an observable difference between using an nested opaque and using an (currently not otherwise expressable) item bound?

Yep, since we're not introducing a new RPIT here, we don't need to care about captures (especially higher-ranked ones). See the test:

rust/tests/ui/associated-type-bounds/higher-ranked.rs

Lines 1 to 17 in 96561a8

    
           //@ check-pass 
        
           #![feature(associated_type_bounds)] 
        
           trait A<'a> { 
        
               type Assoc: ?Sized; 
        
           } 
        
           impl<'a> A<'a> for () { 
        
               type Assoc = &'a (); 
        
           } 
        
           fn hello() -> impl for<'a> A<'a, Assoc: Sized> { 
        
               () 
        
           } 
        
           fn main() {}

Specifically, impl for<'a> A<'a, Assoc: Sized> is more powerful in impl for<'a> A<'a, Assoc = impl Sized + 'a>. I consider this to be a good thing, for the record.

oli-obk · 2024-03-07T11:24:54Z

I think it's somewhat obvious, but, uh, maybe mention in the main post that this is an insta-stable change 😆

So... this change can't break any code, because either it was erroring before due to the bound not being satisfied, or it already had the bound explicitly. There is no situation where the new implied bound in param env is now preferred over looking at global information?

lcnr · 2024-03-07T11:37:12Z

There is no situation where the new implied bound in param env is now preferred over looking at global information?

🤔 it only affects rigid associated types, and at this point impls don't really apply to it. I guess it can impact inference for <<This as Trait>::Assoc as Other>::Assoc: Bound<?x> where there's now an item bound constraining ?x, but also an always applicable impl for impl<T, U> Trait<U> for T.

I don't expect this to ever happen in practice, but it would be theoretically breaking:

trait Bound<T> {}
impl<T, U> Bound<T> for U {}

trait Trait
where
    <<Self as Trait>::Assoc as Other>::Assoc: Bound<u32>,
{
    type Assoc: Other;
}

trait Other {
    type Assoc;
}

fn impls_trait<T: Bound<U>, U>() -> Vec<U> { vec![] }

fn foo<T: Trait>() {
    let mut vec_u = impls_trait::<<<T as Trait>::Assoc as Other>::Assoc, _>();
    vec_u.sort();
    drop::<Vec<u8>>(vec_u);
}

fn main() {}

please add this as a test 😁

oli-obk · 2024-03-07T11:44:00Z

I don't expect this to ever happen in practice, but it would be theoretically breaking:

thanks. I imagined something like that but was unable to actually build the test 😆

…li-obk Stabilize associated type bounds (RFC 2289) This PR stabilizes associated type bounds, which were laid out in [RFC 2289]. This gives us a shorthand to express nested type bounds that would otherwise need to be expressed with nested `impl Trait` or broken into several `where` clauses. ### What are we stabilizing? We're stabilizing the associated item bounds syntax, which allows us to put bounds in associated type position within other bounds, i.e. `T: Trait<Assoc: Bounds...>`. See [RFC 2289] for motivation. In all position, the associated type bound syntax expands into a set of two (or more) bounds, and never anything else (see "How does this differ[...]" section for more info). Associated type bounds are stabilized in four positions: * **`where` clauses (and APIT)** - This is equivalent to breaking up the bound into two (or more) `where` clauses. For example, `where T: Trait<Assoc: Bound>` is equivalent to `where T: Trait, <T as Trait>::Assoc: Bound`. * **Supertraits** - Similar to above, `trait CopyIterator: Iterator<Item: Copy> {}`. This is almost equivalent to breaking up the bound into two (or more) `where` clauses; however, the bound on the associated item is implied whenever the trait is used. See rust-lang#112573/rust-lang#112629. * **Associated type item bounds** - This allows constraining the *nested* rigid projections that are associated with a trait's associated types. e.g. `trait Trait { type Assoc: Trait2<Assoc2: Copy>; }`. * **opaque item bounds (RPIT, TAIT)** - This allows constraining associated types that are associated with the opaque without having to *name* the opaque. For example, `impl Iterator<Item: Copy>` defines an iterator whose item is `Copy` without having to actually name that item bound. The latter three are not expressible in surface Rust (though for associated type item bounds, this will change in rust-lang#120752, which I don't believe should block this PR), so this does represent a slight expansion of what can be expressed in trait bounds. ### How does this differ from the RFC? Compared to the RFC, the current implementation *always* desugars associated type bounds to sets of `ty::Clause`s internally. Specifically, it does *not* introduce a position-dependent desugaring as laid out in [RFC 2289], and in particular: * It does *not* desugar to anonymous associated items in associated type item bounds. * It does *not* desugar to nested RPITs in RPIT bounds, nor nested TAITs in TAIT bounds. This position-dependent desugaring laid out in the RFC existed simply to side-step limitations of the trait solver, which have mostly been fixed in rust-lang#120584. The desugaring laid out in the RFC also added unnecessary complication to the design of the feature, and introduces its own limitations to, for example: * Conditionally lowering to nested `impl Trait` in certain positions such as RPIT and TAIT means that we inherit the limitations of RPIT/TAIT, namely lack of support for higher-ranked opaque inference. See this code example: rust-lang#120752 (comment). * Introducing anonymous associated types makes traits no longer object safe, since anonymous associated types are not nameable, and all associated types must be named in `dyn` types. This last point motivates why this PR is *not* stabilizing support for associated type bounds in `dyn` types, e.g, `dyn Assoc<Item: Bound>`. Why? Because `dyn` types need to have *concrete* types for all associated items, this would necessitate a distinct lowering for associated type bounds, which seems both complicated and unnecessary compared to just requiring the user to write `impl Trait` themselves. See rust-lang#120719. ### Implementation history: Limited to the significant behavioral changes and fixes and relevant PRs, ping me if I left something out-- * rust-lang#57428 * rust-lang#108063 * rust-lang#110512 * rust-lang#112629 * rust-lang#120719 * rust-lang#120584 Closes rust-lang#52662 [RFC 2289]: https://rust-lang.github.io/rfcs/2289-associated-type-bounds.html

…-obk Stabilize associated type bounds (RFC 2289) This PR stabilizes associated type bounds, which were laid out in [RFC 2289]. This gives us a shorthand to express nested type bounds that would otherwise need to be expressed with nested `impl Trait` or broken into several `where` clauses. ### What are we stabilizing? We're stabilizing the associated item bounds syntax, which allows us to put bounds in associated type position within other bounds, i.e. `T: Trait<Assoc: Bounds...>`. See [RFC 2289] for motivation. In all position, the associated type bound syntax expands into a set of two (or more) bounds, and never anything else (see "How does this differ[...]" section for more info). Associated type bounds are stabilized in four positions: * **`where` clauses (and APIT)** - This is equivalent to breaking up the bound into two (or more) `where` clauses. For example, `where T: Trait<Assoc: Bound>` is equivalent to `where T: Trait, <T as Trait>::Assoc: Bound`. * **Supertraits** - Similar to above, `trait CopyIterator: Iterator<Item: Copy> {}`. This is almost equivalent to breaking up the bound into two (or more) `where` clauses; however, the bound on the associated item is implied whenever the trait is used. See rust-lang#112573/rust-lang#112629. * **Associated type item bounds** - This allows constraining the *nested* rigid projections that are associated with a trait's associated types. e.g. `trait Trait { type Assoc: Trait2<Assoc2: Copy>; }`. * **opaque item bounds (RPIT, TAIT)** - This allows constraining associated types that are associated with the opaque without having to *name* the opaque. For example, `impl Iterator<Item: Copy>` defines an iterator whose item is `Copy` without having to actually name that item bound. The latter three are not expressible in surface Rust (though for associated type item bounds, this will change in rust-lang#120752, which I don't believe should block this PR), so this does represent a slight expansion of what can be expressed in trait bounds. ### How does this differ from the RFC? Compared to the RFC, the current implementation *always* desugars associated type bounds to sets of `ty::Clause`s internally. Specifically, it does *not* introduce a position-dependent desugaring as laid out in [RFC 2289], and in particular: * It does *not* desugar to anonymous associated items in associated type item bounds. * It does *not* desugar to nested RPITs in RPIT bounds, nor nested TAITs in TAIT bounds. This position-dependent desugaring laid out in the RFC existed simply to side-step limitations of the trait solver, which have mostly been fixed in rust-lang#120584. The desugaring laid out in the RFC also added unnecessary complication to the design of the feature, and introduces its own limitations to, for example: * Conditionally lowering to nested `impl Trait` in certain positions such as RPIT and TAIT means that we inherit the limitations of RPIT/TAIT, namely lack of support for higher-ranked opaque inference. See this code example: rust-lang#120752 (comment). * Introducing anonymous associated types makes traits no longer object safe, since anonymous associated types are not nameable, and all associated types must be named in `dyn` types. This last point motivates why this PR is *not* stabilizing support for associated type bounds in `dyn` types, e.g, `dyn Assoc<Item: Bound>`. Why? Because `dyn` types need to have *concrete* types for all associated items, this would necessitate a distinct lowering for associated type bounds, which seems both complicated and unnecessary compared to just requiring the user to write `impl Trait` themselves. See rust-lang#120719. ### Implementation history: Limited to the significant behavioral changes and fixes and relevant PRs, ping me if I left something out-- * rust-lang#57428 * rust-lang#108063 * rust-lang#110512 * rust-lang#112629 * rust-lang#120719 * rust-lang#120584 Closes rust-lang#52662 [RFC 2289]: https://rust-lang.github.io/rfcs/2289-associated-type-bounds.html

Stabilize associated type bounds (RFC 2289) This PR stabilizes associated type bounds, which were laid out in [RFC 2289]. This gives us a shorthand to express nested type bounds that would otherwise need to be expressed with nested `impl Trait` or broken into several `where` clauses. ### What are we stabilizing? We're stabilizing the associated item bounds syntax, which allows us to put bounds in associated type position within other bounds, i.e. `T: Trait<Assoc: Bounds...>`. See [RFC 2289] for motivation. In all position, the associated type bound syntax expands into a set of two (or more) bounds, and never anything else (see "How does this differ[...]" section for more info). Associated type bounds are stabilized in four positions: * **`where` clauses (and APIT)** - This is equivalent to breaking up the bound into two (or more) `where` clauses. For example, `where T: Trait<Assoc: Bound>` is equivalent to `where T: Trait, <T as Trait>::Assoc: Bound`. * **Supertraits** - Similar to above, `trait CopyIterator: Iterator<Item: Copy> {}`. This is almost equivalent to breaking up the bound into two (or more) `where` clauses; however, the bound on the associated item is implied whenever the trait is used. See #112573/#112629. * **Associated type item bounds** - This allows constraining the *nested* rigid projections that are associated with a trait's associated types. e.g. `trait Trait { type Assoc: Trait2<Assoc2: Copy>; }`. * **opaque item bounds (RPIT, TAIT)** - This allows constraining associated types that are associated with the opaque without having to *name* the opaque. For example, `impl Iterator<Item: Copy>` defines an iterator whose item is `Copy` without having to actually name that item bound. The latter three are not expressible in surface Rust (though for associated type item bounds, this will change in #120752, which I don't believe should block this PR), so this does represent a slight expansion of what can be expressed in trait bounds. ### How does this differ from the RFC? Compared to the RFC, the current implementation *always* desugars associated type bounds to sets of `ty::Clause`s internally. Specifically, it does *not* introduce a position-dependent desugaring as laid out in [RFC 2289], and in particular: * It does *not* desugar to anonymous associated items in associated type item bounds. * It does *not* desugar to nested RPITs in RPIT bounds, nor nested TAITs in TAIT bounds. This position-dependent desugaring laid out in the RFC existed simply to side-step limitations of the trait solver, which have mostly been fixed in #120584. The desugaring laid out in the RFC also added unnecessary complication to the design of the feature, and introduces its own limitations to, for example: * Conditionally lowering to nested `impl Trait` in certain positions such as RPIT and TAIT means that we inherit the limitations of RPIT/TAIT, namely lack of support for higher-ranked opaque inference. See this code example: rust-lang/rust#120752 (comment). * Introducing anonymous associated types makes traits no longer object safe, since anonymous associated types are not nameable, and all associated types must be named in `dyn` types. This last point motivates why this PR is *not* stabilizing support for associated type bounds in `dyn` types, e.g, `dyn Assoc<Item: Bound>`. Why? Because `dyn` types need to have *concrete* types for all associated items, this would necessitate a distinct lowering for associated type bounds, which seems both complicated and unnecessary compared to just requiring the user to write `impl Trait` themselves. See #120719. ### Implementation history: Limited to the significant behavioral changes and fixes and relevant PRs, ping me if I left something out-- * #57428 * #108063 * #110512 * #112629 * #120719 * #120584 Closes #52662 [RFC 2289]: https://rust-lang.github.io/rfcs/2289-associated-type-bounds.html

bors · 2024-03-21T08:22:18Z

☔ The latest upstream changes (presumably #121123) made this pull request unmergeable. Please resolve the merge conflicts.

Stabilize associated type bounds (RFC 2289) This PR stabilizes associated type bounds, which were laid out in [RFC 2289]. This gives us a shorthand to express nested type bounds that would otherwise need to be expressed with nested `impl Trait` or broken into several `where` clauses. ### What are we stabilizing? We're stabilizing the associated item bounds syntax, which allows us to put bounds in associated type position within other bounds, i.e. `T: Trait<Assoc: Bounds...>`. See [RFC 2289] for motivation. In all position, the associated type bound syntax expands into a set of two (or more) bounds, and never anything else (see "How does this differ[...]" section for more info). Associated type bounds are stabilized in four positions: * **`where` clauses (and APIT)** - This is equivalent to breaking up the bound into two (or more) `where` clauses. For example, `where T: Trait<Assoc: Bound>` is equivalent to `where T: Trait, <T as Trait>::Assoc: Bound`. * **Supertraits** - Similar to above, `trait CopyIterator: Iterator<Item: Copy> {}`. This is almost equivalent to breaking up the bound into two (or more) `where` clauses; however, the bound on the associated item is implied whenever the trait is used. See #112573/#112629. * **Associated type item bounds** - This allows constraining the *nested* rigid projections that are associated with a trait's associated types. e.g. `trait Trait { type Assoc: Trait2<Assoc2: Copy>; }`. * **opaque item bounds (RPIT, TAIT)** - This allows constraining associated types that are associated with the opaque without having to *name* the opaque. For example, `impl Iterator<Item: Copy>` defines an iterator whose item is `Copy` without having to actually name that item bound. The latter three are not expressible in surface Rust (though for associated type item bounds, this will change in #120752, which I don't believe should block this PR), so this does represent a slight expansion of what can be expressed in trait bounds. ### How does this differ from the RFC? Compared to the RFC, the current implementation *always* desugars associated type bounds to sets of `ty::Clause`s internally. Specifically, it does *not* introduce a position-dependent desugaring as laid out in [RFC 2289], and in particular: * It does *not* desugar to anonymous associated items in associated type item bounds. * It does *not* desugar to nested RPITs in RPIT bounds, nor nested TAITs in TAIT bounds. This position-dependent desugaring laid out in the RFC existed simply to side-step limitations of the trait solver, which have mostly been fixed in #120584. The desugaring laid out in the RFC also added unnecessary complication to the design of the feature, and introduces its own limitations to, for example: * Conditionally lowering to nested `impl Trait` in certain positions such as RPIT and TAIT means that we inherit the limitations of RPIT/TAIT, namely lack of support for higher-ranked opaque inference. See this code example: rust-lang/rust#120752 (comment). * Introducing anonymous associated types makes traits no longer object safe, since anonymous associated types are not nameable, and all associated types must be named in `dyn` types. This last point motivates why this PR is *not* stabilizing support for associated type bounds in `dyn` types, e.g, `dyn Assoc<Item: Bound>`. Why? Because `dyn` types need to have *concrete* types for all associated items, this would necessitate a distinct lowering for associated type bounds, which seems both complicated and unnecessary compared to just requiring the user to write `impl Trait` themselves. See #120719. ### Implementation history: Limited to the significant behavioral changes and fixes and relevant PRs, ping me if I left something out-- * #57428 * #108063 * #110512 * #112629 * #120719 * #120584 Closes #52662 [RFC 2289]: https://rust-lang.github.io/rfcs/2289-associated-type-bounds.html

nikomatsakis · 2024-06-09T10:10:27Z

@rfcbot reviewed

rfcbot · 2024-06-09T10:10:40Z

🔔 This is now entering its final comment period, as per the review above. 🔔

rfcbot · 2024-06-19T10:12:13Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

rustbot assigned lcnr Feb 7, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative labels Feb 7, 2024

lcnr added the needs-fcp This change is insta-stable, so needs a completed FCP to proceed. label Feb 8, 2024

rust-cloud-vms bot force-pushed the more-relevant-bounds branch from fa551a1 to 35d8667 Compare March 4, 2024 19:59

This comment has been minimized.

Sign in to view

Collect relevant item bounds from trait clauses for nested rigid proj…

98fcb15

…ections, GATs

rust-cloud-vms bot force-pushed the more-relevant-bounds branch from 35d8667 to 98fcb15 Compare March 4, 2024 20:16

compiler-errors marked this pull request as ready for review March 5, 2024 17:56

lcnr approved these changes Mar 5, 2024

View reviewed changes

lcnr added T-types Relevant to the types team, which will review and decide on the PR/issue. and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 5, 2024

rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Mar 5, 2024

compiler-errors mentioned this pull request Mar 6, 2024

Stabilize associated type bounds (RFC 2289) #122055

Merged

oli-obk approved these changes Mar 7, 2024

View reviewed changes

compiler-errors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 7, 2024

lcnr mentioned this pull request Mar 21, 2024

Make inductive cycles always ambiguous #122791

Merged

compiler-errors removed the needs-fcp This change is insta-stable, so needs a completed FCP to proceed. label May 21, 2024

rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Jun 9, 2024

rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Jun 9, 2024

apiraino removed the to-announce Announce this issue on triage meeting label Jul 4, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Collect relevant item bounds from trait clauses for nested rigid projections #120752

Collect relevant item bounds from trait clauses for nested rigid projections #120752

compiler-errors commented Feb 7, 2024 •

edited

Loading

lcnr commented Feb 8, 2024 •

edited

Loading

compiler-errors commented Mar 2, 2024

lcnr commented Mar 4, 2024

compiler-errors commented Mar 4, 2024

This comment has been minimized.

compiler-errors commented Mar 5, 2024

lcnr left a comment

lcnr Mar 5, 2024

lcnr Mar 5, 2024

lcnr commented Mar 5, 2024

rfcbot commented Mar 5, 2024 •

edited

Loading

compiler-errors commented Mar 5, 2024 •

edited

Loading

lcnr commented Mar 5, 2024 •

edited

Loading

compiler-errors commented Mar 5, 2024

oli-obk commented Mar 7, 2024

lcnr commented Mar 7, 2024

oli-obk commented Mar 7, 2024

bors commented Mar 21, 2024

nikomatsakis commented Jun 9, 2024

rfcbot commented Jun 9, 2024

rfcbot commented Jun 19, 2024

Collect relevant item bounds from trait clauses for nested rigid projections #120752

Are you sure you want to change the base?

Collect relevant item bounds from trait clauses for nested rigid projections #120752

Conversation

compiler-errors commented Feb 7, 2024 • edited Loading

Background

Problem 1: GATs don't uplift bounds correctly

Problem 2: Nested associated type bounds are not uplifted

How does this PR fix things?

Okay, but does this really matter?

lcnr commented Feb 8, 2024 • edited Loading

compiler-errors commented Mar 2, 2024

lcnr commented Mar 4, 2024

compiler-errors commented Mar 4, 2024

This comment has been minimized.

compiler-errors commented Mar 5, 2024

lcnr left a comment

Choose a reason for hiding this comment

lcnr Mar 5, 2024

Choose a reason for hiding this comment

lcnr Mar 5, 2024

Choose a reason for hiding this comment

lcnr commented Mar 5, 2024

rfcbot commented Mar 5, 2024 • edited Loading

compiler-errors commented Mar 5, 2024 • edited Loading

lcnr commented Mar 5, 2024 • edited Loading

compiler-errors commented Mar 5, 2024

oli-obk commented Mar 7, 2024

lcnr commented Mar 7, 2024

oli-obk commented Mar 7, 2024

bors commented Mar 21, 2024

nikomatsakis commented Jun 9, 2024

rfcbot commented Jun 9, 2024

rfcbot commented Jun 19, 2024

compiler-errors commented Feb 7, 2024 •

edited

Loading

lcnr commented Feb 8, 2024 •

edited

Loading

rfcbot commented Mar 5, 2024 •

edited

Loading

compiler-errors commented Mar 5, 2024 •

edited

Loading

lcnr commented Mar 5, 2024 •

edited

Loading