Generic Associated Types Parsing & Name Resolution #45904

sunjay · 2017-11-10T04:08:52Z

Hi!
This PR adds parsing for generic associated types! 🎉 🎉 🎉

Tracking Issue: #44265

Notes For Reviewers

I still need to add the stdout and stderr files to my ui tests. It takes me a long time to compile the compiler locally, so I'm going to add this as soon as possible in the next day or so.
My current ui tests aren't very good or very thorough. I'm reusing the parse_generics and parse_where_clause methods from elsewhere in the parser, so my changes work without being particularly complex. I'm not sure if I should duplicate all of the generics test cases for generic associated types. It might actually be appropriate to duplicate everything here, since we don't want to rely on an implementation detail in case it changes in the future. If you think so too, I'll adapt all of the generics test cases into the generic associated types test cases.
There is still more work required to make the run-pass tests pass here. In particular, we need to make the following errors disappear:

error[E0110]: lifetime parameters are not allowed on this type
  --> ./src/test/run-pass/rfc1598-generic-associated-types/streaming_iterator.rs:23:41
   |
23 |     bar: <T as StreamingIterator>::Item<'static>,
   |                                         ^^^^^^^ lifetime parameter not allowed on this type

error[E0261]: use of undeclared lifetime name `'a`
  --> ./src/test/run-pass/rfc1598-generic-associated-types/iterable.rs:15:47
   |
15 |     type Iter<'a>: Iterator<Item = Self::Item<'a>>;
   |                                               ^^ undeclared lifetime

There is a FIXME comment in streaming_iterator. If you uncomment that line, you get the following:

error: expected one of `!`, `+`, `,`, `::`, or `>`, found `=`
  --> ./src/test/run-pass/rfc1598-generic-associated-types/streaming_iterator.rs:29:45
   |
29 | fn foo<T: for<'a> StreamingIterator<Item<'a>=&'a [i32]>>(iter: T) { /* ... */ }
   |                                             ^ expected one of `!`, `+`, `,`, `::`, or `>` here

r? @nikomatsakis

sunjay · 2017-11-10T04:12:24Z

src/test/ui/rfc1598-generic-associated-types/generic_associated_types_equals.rs

+
+trait Foo {
+    type Bar<T=usize>;
+    type X<T> where T = f64;


@nikomatsakis Are we going to support type defaults as part of this RFC? If not, this test can be removed.

I would be inclined to have them work "as much as they do for regular associated types" (they are presently unstable there because we never could agree on the full semantics). It'd probably be more work to try and ban them.

However, this is not the default syntax. Or maybe I didn't understand what you meant. The syntax might be more like:

type X<T> = f64;

Maybe try something like this, which is basically the prime use-case:

trait Iterable { type Iter<'a>: Iterator; }

Note that, in particular, I don't think we plan -- yet -- to support GATs with type parameters (we will eventually, we have to fixup some stuff in our trait system impl first). We should definitely parse them and so forth though.

nikomatsakis · 2017-11-10T21:23:37Z

src/test/ui/rfc1598-generic-associated-types/generic_associated_types_equals.rs

+#![feature(generic_associated_types)]
+
+trait Foo {
+    type Bar<T=usize>;


This form of default we will definitely not support.

This form of default we will definitely not support.

This is the kind of information I was looking for since that will allow me to figure out which test cases I need to add to make sure we explicitly reject it. :)

It will likely parse, it just ought to be rejected elsewhere, later in the compiler.

petrochenkov · 2017-11-11T22:22:38Z

src/libsyntax/parse/parser.rs

            self.expect(&token::Eq)?;
            let typ = self.parse_ty()?;
+            generics.where_clause = self.parse_where_clause()?;


This is a syntax mismatch between usual type aliases and associated types.

// Existing type alias syntax type UsualAlias<'a, T> where T: Copy = u8; // Associated type syntax as implemented here. type AssociatedAlias<'a, T> = u8 where T: Copy;

petrochenkov · 2017-11-11T22:29:12Z

src/libsyntax/parse/parser.rs

+        } else {
+            None
+        };
+        generics.where_clause = self.parse_where_clause()?;


Again, the where clause is in unexpected position

// As implemented here type AssociatedAlias<'a, T>: Trait + 'static = u8 /* body */ where T: Copy;

while I would expect it to be

type AssociatedAlias<'a, T>: Trait + 'static where T: Copy = u8 /* body */;

, i.e. consistent with existing type aliases and traits

type UsualAlias<'a, T> where T: Copy = u8 /* body */; type MyTrait<'a, T>: Trait + 'static where T: Copy { /* body */ }

Thanks! I was wondering about this too. I'll correct it. 😄

bors · 2017-11-12T09:50:07Z

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

nikomatsakis · 2017-11-14T16:15:41Z

src/libsyntax/feature_gate.rs

@@ -1595,6 +1598,10 @@ impl<'a> Visitor<'a> for PostExpansionVisitor<'a> {
                gate_feature_post!(&self, associated_type_defaults, ti.span,
                                  "associated type defaults are unstable");
            }
+            _ if ti.generics.is_parameterized() => {


This is applying now to all kinds of trait items besides methods and types with a default value. This strikes me as a bit confusing. I think we should refactor this to be more like:

match ti.node { ast::TraitItemKind::Method(ref sig, ref block) => { .. /* as today */ .. } ast::TraitItemKind::Type(_, default) => { if default.is_some() { gate_feature_post!(&self, associated_type_defaults, ti.span, "associated type defaults are unstable"); } if ti.generics.is_parameterized() { gate_feature_post!(&self, generic_associated_types, ti.span, "generic associated types are unstable"); } } _ => { /* nothing unstable here */ } }

nikomatsakis

I pushed some examples of how we could write "successful parse" tests.

nikomatsakis · 2017-11-14T16:16:07Z

src/libsyntax/feature_gate.rs

@@ -1613,6 +1620,10 @@ impl<'a> Visitor<'a> for PostExpansionVisitor<'a> {
                    gate_feature_post!(&self, const_fn, ii.span, "const fn is unstable");
                }
            }
+            _ if ii.generics.is_parameterized() => {


As above, I would rather this be specific to ast::ImplItemKind::Type.

nikomatsakis · 2017-11-14T16:18:06Z

src/libsyntax/parse/parser.rs

@@ -4437,6 +4438,36 @@ impl<'a> Parser<'a> {
        })
    }

+    fn parse_trait_item_assoc_ty(&mut self, preceding_attrs: Vec<Attribute>)


Can we comment this with the grammar it consumes? I believe

TraitItemAssocTy = Ident ["<"...">"] [":" [TyParamBounds]] ["where" ...] ["=" Ty]

would be correct (after applying @petrochenkov's correction to where the where clause parsing goes.

Is there a reason why parse_trait_item_assoc_ty doesn't consume the semicolon? I think it really could given that it's only used in one place and it wouldn't make any sense to parse all of this without the semicolon at the end.

nikomatsakis · 2017-11-14T16:19:10Z

src/libsyntax/parse/parser.rs

@@ -4979,10 +5010,12 @@ impl<'a> Parser<'a> {
        let defaultness = self.parse_defaultness()?;
        let (name, node, generics) = if self.eat_keyword(keywords::Type) {
            let name = self.parse_ident()?;


Again, a comment with the grammar would be nice (not your fault, should have been one there before for you to edit).

nikomatsakis · 2017-11-14T16:20:37Z

src/test/compile-fail/feature-gate-generic_associated_types.rs

+use std::ops::Deref;
+
+trait PointerFamily {
+    type Pointer<T>: Deref<Target = T>;


Isn't some sort of error expected here? I think you will need a //~ ERROR annotation.

Also, can we include in this test impl Foo { type Pointer<T> = (); } and impl Trait for Foo { type Pointer<U> = (); }?

nikomatsakis · 2017-11-14T16:27:40Z

src/test/run-pass/rfc1598-generic-associated-types/construct_with_other_type.rs

+
+trait Foo {
+    type Bar<'a, 'b>;
+}


Are these tests just intended to test parsing? We could actually test that by doing two things:

Move the files into a parse-fail/generic-associated-types/ directory

Add // compile-flags: -Zparse-only to the top. This will cause rustc to stop after parsing.

Add // must-compile-successfully to the top. This will cause the test to pass if no errors are reported.

If we want to add tests for things that should not parse, we can do that too, just remove must-compile-successfully and add //~ ERROR lines.

I think that will work just fine.

I was originally going to suggest using the parse-fail directory, but ui seems better since then we get to see the parse error messages, which are interesting.

It'd be good to try and make a relatively "exhaustive" set of tests exploring the various permutations of what is optional and not optional.

I think I have done this in the parse tests that you started earlier. Please take a look. :)

nikomatsakis · 2017-11-14T16:48:26Z

src/test/run-pass/rfc1598-generic-associated-types/generic-associated-types-where.rs

+trait Foo {
+    type Assoc where Self: Sized;
+    type Assoc2<T> where T: Display;
+    type WithDefault<T> = Iterator<Item=T> where T: Debug;


As @petrochenkov noted, where clause in wrong place.

nikomatsakis · 2017-11-14T16:49:18Z

src/test/run-pass/rfc1598-generic-associated-types/streaming_iterator.rs

+// Users can bound parameters by the type constructed by that trait's associated type constructor
+// of a trait using HRTB. Both type equality bounds and trait bounds of this kind are valid:
+//FIXME(sunjay): This next line should parse and be valid
+//fn foo<T: for<'a> StreamingIterator<Item<'a>=&'a [i32]>>(iter: T) { /* ... */ }


Are we going to try and handle this in this PR, or leave as a FIXME? I advocate the latter.

This requires more changes to the parser. I don't think those changes should be hard given what I've had to do so far. That being said, if you think it's best to leave it until later I'm okay with that too. Let's just make sure that we don't forget to fix it later on 😄

This will also require changes to the AST and HIR; I'm inclined to leave those for a separate series of PRs.

Sounds good! I will leave it then.

nikomatsakis · 2017-11-14T16:50:16Z

src/test/ui/rfc1598-generic-associated-types/generic_associated_types_equals.rs

+#![feature(generic_associated_types)]
+
+trait Foo {
+    type Bar<T=usize>;


It will likely parse, it just ought to be rejected elsewhere, later in the compiler.

nikomatsakis · 2017-11-14T17:19:24Z

(In my example test I went a bit overboard testing the generics parsing; since that's re-using something existing, it's not really needed.)

sunjay · 2017-11-19T05:20:04Z

src/libsyntax/parse/parser.rs

@@ -4437,6 +4438,38 @@ impl<'a> Parser<'a> {
        })
    }

+    /// Parses the following grammar:
+    ///     TraitItemAssocTy = Ident ["<"...">"] [":" [TyParamBounds]] ["where" ...] ["=" Ty]
+    fn parse_trait_item_assoc_ty(&mut self, preceding_attrs: Vec<Attribute>)


@nikomatsakis Is there a reason why parse_trait_item_assoc_ty doesn't consume the semicolon? I think it really could given that it's only used in one place and it wouldn't make any sense to parse all of this without the semicolon at the end. The only invocation of this function immediately expects a semicolon right after it.

(added this question again because GitHub removed it on the latest diff)

It doesn't make a big difference either way. A lot of times it's good to leave separators and terminators out from functions like this, since it makes them more re-usable, but I think in this case the ; logically "belongs" to the trait item, so it would make sense for this function to consume it.

In the latest code, the semicolon is consumed.

sunjay · 2017-11-19T05:20:39Z

src/libsyntax/parse/parser.rs

        } else if self.is_const_item() {
+            // This parses the grammar:
+            //     ImplItemConst = "const" Ident ":" Ty "=" Expr ";"


This comment isn't relevant to what I'm adding, but I added it because @nikomatsakis mentioned that it's good to document the grammar in places like this

bors · 2017-11-21T15:13:30Z

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

sunjay · 2017-11-22T18:29:42Z

The name resolution PR (#46146) has been merged into this PR. Once I fix the tests, this should be ready to go!

sunjay · 2017-11-22T22:09:49Z

@nikomatsakis Extensions to the parser that will be made soon but not as part of this PR:

type Quux<'a> = <T as Foo>::Bar<'a, 'static>;
fn foo<T: for<'a> StreamingIterator<Item<'a>=&'a [i32]>>(iter: T) { /* ... */ }

bors · 2017-11-23T10:50:09Z

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

sunjay · 2017-11-26T03:48:35Z

src/test/ui/rfc1598-generic-associated-types/parse/in-trait.rs

+    type Bar<'a, 'b, T: Debug, U,>: Deref<Target = T> + Into<U>;
+    type Bar<'a, 'b, T: Debug, U,> where T: Deref<Target = U>, U: Into<T>;
+    type Bar<'a, 'b, T: Debug, U,>: Deref<Target = T> + Into<U>
+        where T: Deref<Target = U>, U: Into<T>;


@nikomatsakis I extended this with quite a few cases. Let me know if there is anything important that I missed. (It's probably not totally exhaustive, but I believe I have covered the major cases.)

Note: This code is pretty much nonsense as far as its meaning goes, but that's okay because it's just really meant to test parsing.

nikomatsakis

Looks good!

nikomatsakis · 2017-11-29T10:01:03Z

src/test/ui/rfc1598-generic-associated-types/generic-associated-types-where.rs

+
+impl Foo for Bar {
+    type Assoc = usize;
+    type Assoc2<T> = Vec<T>;


Maybe also add type Assoc3<T> where T: Iterator = Vec<T>?

But it's not super important.

It's added below this comment. Please r+ once again. :)

nikomatsakis · 2017-11-29T15:58:46Z

@bors r+

bors · 2017-11-29T15:58:48Z

📌 Commit 11613a0 has been approved by nikomatsakis

nikomatsakis · 2017-11-30T20:19:14Z

Test failure.

arielb1 · 2017-11-30T20:58:42Z

@bors r-

…pe declarations

…ld which was never used. Lifting the HasTypeParameters rib to all trait item kinds and all impl item kinds

…with appropriate fixme comments

sunjay · 2017-12-01T06:27:27Z

Rebased. Should be mergeable again.

nikomatsakis · 2017-12-01T21:37:43Z

@bors r+

bors · 2017-12-01T21:37:43Z

📌 Commit 9d5592b has been approved by nikomatsakis

bors · 2017-12-02T00:15:27Z

⌛ Testing commit 9d5592b with merge ddaebe9...

@nikomatsakis

Generic Associated Types Parsing & Name Resolution Hi! This PR adds parsing for generic associated types! 🎉 🎉 🎉 Tracking Issue: #44265 ## Notes For Reviewers * [x] I still need to add the stdout and stderr files to my ui tests. It takes me a *long* time to compile the compiler locally, so I'm going to add this as soon as possible in the next day or so. * [ ] My current ui tests aren't very good or very thorough. I'm reusing the `parse_generics` and `parse_where_clause` methods from elsewhere in the parser, so my changes work without being particularly complex. I'm not sure if I should duplicate all of the generics test cases for generic associated types. It might actually be appropriate to duplicate everything here, since we don't want to rely on an implementation detail in case it changes in the future. If you think so too, I'll adapt all of the generics test cases into the generic associated types test cases. * [ ] There is still more work required to make the run-pass tests pass here. In particular, we need to make the following errors disappear: ``` error[E0110]: lifetime parameters are not allowed on this type --> ./src/test/run-pass/rfc1598-generic-associated-types/streaming_iterator.rs:23:41 | 23 | bar: <T as StreamingIterator>::Item<'static>, | ^^^^^^^ lifetime parameter not allowed on this type ``` ``` error[E0261]: use of undeclared lifetime name `'a` --> ./src/test/run-pass/rfc1598-generic-associated-types/iterable.rs:15:47 | 15 | type Iter<'a>: Iterator<Item = Self::Item<'a>>; | ^^ undeclared lifetime ``` There is a FIXME comment in streaming_iterator. If you uncomment that line, you get the following: ``` error: expected one of `!`, `+`, `,`, `::`, or `>`, found `=` --> ./src/test/run-pass/rfc1598-generic-associated-types/streaming_iterator.rs:29:45 | 29 | fn foo<T: for<'a> StreamingIterator<Item<'a>=&'a [i32]>>(iter: T) { /* ... */ } | ^ expected one of `!`, `+`, `,`, `::`, or `>` here ``` r? @nikomatsakis

bors · 2017-12-02T02:56:10Z

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing ddaebe9 to master...

sunjay · 2017-12-02T02:57:58Z

🎉 🎉 🎉 🎉 🎉

…er-errors Stabilize generic associated types Closes rust-lang#44265 r? `@nikomatsakis` # ⚡ Status of the discussion ⚡ * [x] There have been several serious concerns raised, [summarized here](rust-lang#96709 (comment)). * [x] There has also been a [deep-dive comment](rust-lang#96709 (comment)) explaining some of the "patterns of code" that are enabled by GATs, based on use-cases posted to this thread or on the tracking issue. * [x] We have modeled some aspects of GATs in [a-mir-formality](https://github.com/nikomatsakis/a-mir-formality) to give better confidence in how they will be resolved in the future. [You can read a write-up here](https://github.com/rust-lang/types-team/blob/master/minutes/2022-07-08-implied-bounds-and-wf-checking.md). * [x] The major points of the discussion have been [summarized on the GAT initiative repository](https://rust-lang.github.io/generic-associated-types-initiative/mvp.html). * [x] [FCP has been proposed](rust-lang#96709 (comment)) and we are awaiting final decisions and discussion amidst the relevant team members. # Stabilization proposal This PR proposes the stabilization of `#![feature(generic_associated_types)]`. While there a number of future additions to be made and bugs to be fixed (both discussed below), properly doing these will require significant language design and will ultimately likely be backwards-compatible. Given the overwhelming desire to have some form of generic associated types (GATs) available on stable and the stability of the "simple" uses, stabilizing the current subset of GAT features is almost certainly the correct next step. Tracking issue: rust-lang#44265 Initiative: https://rust-lang.github.io/generic-associated-types-initiative/ RFC: https://github.com/rust-lang/rfcs/blob/master/text/1598-generic_associated_types.md Version: 1.65 (2022-08-22 => beta, 2022-11-03 => stable). ## Motivation There are a myriad of potential use cases for GATs. Stabilization unblocks probable future language features (e.g. async functions in traits), potential future standard library features (e.g. a `LendingIterator` or some form of `Iterator` with a lifetime generic), and a plethora of user use cases (some of which can be seen just by scrolling through the tracking issue and looking at all the issues linking to it). There are a myriad of potential use cases for GATs. First, there are many users that have chosen to not use GATs primarily because they are not stable (some of which can be seen just by scrolling through the tracking issue and looking at all the issues linking to it). Second, while language feature desugaring isn't *blocked* on stabilization, it gives more confidence on using the feature. Likewise, library features like `LendingIterator` are not necessarily blocked on stabilization to be implemented unstably; however few, if any, public-facing APIs actually use unstable features. This feature has a long history of design, discussion, and developement - the RFC was first introduced roughly 6 years ago. While there are still a number of features left to implement and bugs left to fix, it's clear that it's unlikely those will have backwards-incompatibility concerns. Additionally, the bugs that do exist do not strongly impede the most-common use cases. ## What is stabilized The primary language feature stabilized here is the ability to have generics on associated types, as so. Additionally, where clauses on associated types will now be accepted, regardless if the associated type is generic or not. ```rust trait ATraitWithGATs { type Assoc<'a, T> where T: 'a; } trait ATraitWithoutGATs<'a, T> { type Assoc where T: 'a; } ``` When adding an impl for a trait with generic associated types, the generics for the associated type are copied as well. Note that where clauses are allowed both after the specified type and before the equals sign; however, the latter is a warn-by-default deprecation. ```rust struct X; struct Y; impl ATraitWithGATs for X { type Assoc<'a, T> = &'a T where T: 'a; } impl ATraitWithGATs for Y { type Assoc<'a, T> where T: 'a = &'a T; } ``` To use a GAT in a function, generics are specified on the associated type, as if it was a struct or enum. GATs can also be specified in trait bounds: ```rust fn accepts_gat<'a, T>(t: &'a T) -> T::Assoc<'a, T> where for<'x> T: ATraitWithGATs<Assoc<'a, T> = &'a T> { ... } ``` GATs can also appear in trait methods. However, depending on how they are used, they may confer where clauses on the associated type definition. More information can be found [here](rust-lang#87479). Briefly, where clauses are required when those bounds can be proven in the methods that *construct* the GAT or other associated types that use the GAT in the trait. This allows impls to have maximum flexibility in the types defined for the associated type. To take a relatively simple example: ```rust trait Iterable { type Item<'a>; type Iterator<'a>: Iterator<Item = Self::Item<'a>>; fn iter<'x>(&'x self) -> Self::Iterator<'x>; //^ We know that `Self: 'a` for `Iterator<'a>`, so we require that bound on `Iterator` // `Iterator` uses `Self::Item`, so we also require a `Self: 'a` on `Item` too } ``` A couple well-explained examples are available in a previous [blog post](https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html). ## What isn't stabilized/implemented ### Universal type/const quantification Currently, you can write a bound like `X: for<'a> Trait<Assoc<'a> = &'a ()>`. However, you cannot currently write `for<T> X: Trait<Assoc<T> = T>` or `for<const N> X: Trait<Assoc<N> = [usize; N]>`. Here is an example where this is needed: ```rust trait Foo {} trait Trait { type Assoc<F: Foo>; } trait Trait2: Sized { fn foo<F: Foo, T: Trait<Assoc<F> = F>>(_t: T); } ``` In the above example, the *caller* must specify `F`, which is likely not what is desired. ### Object-safe GATs Unlike non-generic associated types, traits with GATs are not currently object-safe. In other words the following are not allowed: ```rust trait Trait { type Assoc<'a>; } fn foo(t: &dyn for<'a> Trait<Assoc<'a> = &'a ()>) {} //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not allowed let ty: Box<dyn for<'a> Trait<Assoc<'a> = &'a ()>>; //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not allowed ``` ### Higher-kinded types You cannot write currently (and there are no current plans to implement this): ```rust struct Struct<'a> {} fn foo(s: for<'a> Struct<'a>) {} ``` ## Tests There are many tests covering GATs that can be found in `src/test/ui/generic-associated-types`. Here, I'll list (in alphanumeric order) tests highlight some important behavior or contain important patterns. - `./parse/*`: Parsing of GATs in traits and impls, and the trait path with GATs - `./collections-project-default.rs`: Interaction with associated type defaults - `./collections.rs`: The `Collection` pattern - `./const-generics-gat-in-trait-return-type-*.rs`: Const parameters - `./constraint-assoc-type-suggestion.rs`: Emit correct syntax in suggestion - `./cross-crate-bounds.rs`: Ensure we handles bounds across crates the same - `./elided-in-expr-position.rs`: Disallow lifetime elision in return position - `./gat-in-trait-path-undeclared-lifetime.rs`: Ensure we error on undeclared lifetime in trait path - `./gat-in-trait-path.rs`: Base trait path case - `./gat-trait-path-generic-type-arg.rs`: Don't allow shadowing of parameters - `./gat-trait-path-parenthesised-args.rs`: Don't allow paranthesized args in trait path - `./generic-associated-types-where.rs`: Ensure that we require where clauses from trait to be met on impl - `./impl_bounds.rs`: Check that the bounds on GATs in an impl are checked - `./issue-76826.rs`: `Windows` pattern - `./issue-78113-lifetime-mismatch-dyn-trait-box.rs`: Implicit 'static diagnostics - `./issue-84931.rs`: Ensure that we have a where clause on GAT to ensure trait parameter lives long enough - `./issue-87258_a.rs`: Unconstrained opaque type with TAITs - `./issue-87429-2.rs`: Ensure we can use bound vars in the bounds - `./issue-87429-associated-type-default.rs`: Ensure bounds hold with associated type defaults, for both trait and impl - `./issue-87429-specialization.rs`: Check that bounds hold under specialization - `./issue-88595.rs`: Under the outlives lint, we require a bound for both trait and GAT lifetime when trait lifetime is used in function - `./issue-90014.rs`: Lifetime bounds are checked with TAITs - `./issue-91139.rs`: Under migrate mode, but not NLL, we don't capture implied bounds from HRTB lifetimes used in a function and GATs - `./issue-91762.rs`: We used to too eagerly pick param env candidates when normalizing with GATs. We now require explicit parameters specified. - `./issue-95305.rs`: Disallow lifetime elision in trait paths - `./iterable.rs`: `Iterable` pattern - `./method-unsatified-assoc-type-predicate.rs`: Print predicates with GATs correctly in method resolve error - `./missing_lifetime_const.rs`: Ensure we must specify lifetime args (not elidable) - `./missing-where-clause-on-trait.rs`: Ensure we don't allow stricter bounds on impl than trait - `./parameter_number_and_kind_impl.rs`: Ensure paramters on GAT in impl match GAT in trait - `./pointer_family.rs`: `PointerFamily` pattern - `./projection-bound-cycle.rs`: Don't allow invalid cycles to prove bounds - `./self-outlives-lint.rs`: Ensures that an e.g. `Self: 'a` is written on the traits GAT if that bound can be implied from the GAT usage in the trait - `./shadowing.rs`: Don't allow lifetime shadowing in params - `./streaming_iterator.rs`: `StreamingIterator`(`LendingIterator`) pattern - `./trait-objects.rs`: Disallow trait objects for traits with GATs - `./variance_constraints.rs`: Require that GAT substs be invariant ## Remaining bugs and open issues A full list of remaining open issues can be found at: https://github.com/rust-lang/rust/labels/F-generic_associated_types There are some `known-bug` tests in-tree at `src/test/ui/generic-associated-types/bugs`. Here I'll categorize most of those that GAT bugs (or involve a pattern found more with GATs), but not those that include GATs but not a GAT issue in and of itself. (I also won't include issues directly for things listed elsewhere here.) Using the concrete type of a GAT instead of the projection type can give errors, since lifetimes are chosen to be early-bound vs late-bound. - rust-lang#85533 - rust-lang#87803 In certain cases, we can run into cycle or overflow errors. This is more generally a problem with associated types. - rust-lang#87755 - rust-lang#87758 Bounds on an associatd type need to be proven by an impl, but where clauses need to be proven by the usage. This can lead to confusion when users write one when they mean the other. - rust-lang#87831 - rust-lang#90573 We sometimes can't normalize closure signatures fully. Really an asociated types issue, but might happen a bit more frequently with GATs, since more obvious place for HRTB lifetimes. - rust-lang#88382 When calling a function, we assign types to parameters "too late", after we already try (and fail) to normalize projections. Another associated types issue that might pop up more with GATs. - rust-lang#88460 - rust-lang#96230 We don't fully have implied bounds for lifetimes appearing in GAT trait paths, which can lead to unconstrained type errors. - rust-lang#88526 Suggestion for adding lifetime bounds can suggest unhelpful fixes (`T: 'a` instead of `Self: 'a`), but the next compiler error after making the suggested change is helpful. - rust-lang#90816 - rust-lang#92096 - rust-lang#95268 We can end up requiring that `for<'a> I: 'a` when we really want `for<'a where I: 'a> I: 'a`. This can leave unhelpful errors than effectively can't be satisfied unless `I: 'static`. Requires bigger changes and not only GATs. - rust-lang#91693 Unlike with non-generic associated types, we don't eagerly normalize with param env candidates. This is intended behavior (for now), to avoid accidentaly stabilizing picking arbitrary impls. - rust-lang#91762 Some Iterator adapter patterns (namely `filter`) require Polonius or unsafe to work. - rust-lang#92985 ## Potential Future work ### Universal type/const quantification No work has been done to implement this. There are also some questions around implied bounds. ### Object-safe GATs The intention is to make traits with GATs object-safe. There are some design work to be done around well-formedness rules and general implementation. ### GATified std lib types It would be helpful to either introduce new std lib traits (like `LendingIterator`) or to modify existing ones (adding a `'a` generic to `Iterator::Item`). There also a number of other candidates, like `Index`/`IndexMut` and `Fn`/`FnMut`/`FnOnce`. ### Reduce the need for `for<'a>` Seen [here](rust-lang/rfcs#1598 (comment)). One possible syntax: ```rust trait Iterable { type Iter<'a>: Iterator<Item = Self::Item<'a>>; } fn foo<T>() where T: Iterable, T::Item<let 'a>: Display { } //note the `let`! ``` ### Better implied bounds on higher-ranked things Currently if we have a `type Item<'a> where self: 'a`, and a `for<'a> T: Iterator<Item<'a> = &'a ()`, this requires `for<'a> Self: 'a`. Really, we want `for<'a where T: 'a> ...` There was some mentions of this all the back in the RFC thread [here](rust-lang/rfcs#1598 (comment)). ## Alternatives ### Make generics on associated type in bounds a binder Imagine the bound `for<'a> T: Trait<Item<'a>= &'a ()>`. It might be that `for<'a>` is "too large" and it should instead be `T: Trait<for<'a> Item<'a>= &'a ()>`. Brought up in RFC thread [here](rust-lang/rfcs#1598 (comment)) and in a few places since. Another related question: Is `for<'a>` the right syntax? Maybe `where<'a>`? Also originally found in RFC thread [here](rust-lang/rfcs#1598 (comment)). ### Stabilize lifetime GATs first This has been brought up a few times. The idea is to only allow GATs with lifetime parameters to in initial stabilization. This was probably most useful prior to actual implementation. At this point, lifetimes, types, and consts are all implemented and work. It feels like an arbitrary split without strong reason. ## History * On 2016-04-30, [RFC opened](rust-lang/rfcs#1598) * On 2017-09-02, RFC merged and [tracking issue opened](rust-lang#44265) * On 2017-10-23, [Move Generics from MethodSig to TraitItem and ImplItem](rust-lang#44766) * On 2017-12-01, [Generic Associated Types Parsing & Name Resolution](rust-lang#45904) * On 2017-12-15, [https://github.com/rust-lang/rust/pull/46706](https://github.com/rust-lang/rust/pull/46706) * On 2018-04-23, [Feature gate where clauses on associated types](rust-lang#49368) * On 2018-05-10, [Extend tests for RFC1598 (GAT)](rust-lang#49423) * On 2018-05-24, [Finish implementing GATs (Chalk)](rust-lang/chalk#134) * On 2019-12-21, [Make GATs less ICE-prone](rust-lang#67160) * On 2020-02-13, [fix lifetime shadowing check in GATs](rust-lang#68938) * On 2020-06-20, [Projection bound validation](rust-lang#72788) * On 2020-10-06, [Separate projection bounds and predicates](rust-lang#73905) * On 2021-02-05, [Generic associated types in trait paths](rust-lang#79554) * On 2021-02-06, [Trait objects do not work with generic associated types](rust-lang#81823) * On 2021-04-28, [Make traits with GATs not object safe](rust-lang#84622) * On 2021-05-11, [Improve diagnostics for GATs](rust-lang#82272) * On 2021-07-16, [Make GATs no longer an incomplete feature](rust-lang#84623) * On 2021-07-16, [Replace associated item bound vars with placeholders when projecting](rust-lang#86993) * On 2021-07-26, [GATs: Decide whether to have defaults for `where Self: 'a`](rust-lang#87479) * On 2021-08-25, [Normalize projections under binders](rust-lang#85499) * On 2021-08-03, [The push for GATs stabilization](https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html) * On 2021-08-12, [Detect stricter constraints on gats where clauses in impls vs trait](rust-lang#88336) * On 2021-09-20, [Proposal: Change syntax of where clauses on type aliases](rust-lang#89122) * On 2021-11-06, [Implementation of GATs outlives lint](rust-lang#89970) * On 2021-12-29. [Parse and suggest moving where clauses after equals for type aliases](rust-lang#92118) * On 2022-01-15, [Ignore static lifetimes for GATs outlives lint](rust-lang#92865) * On 2022-02-08, [Don't constrain projection predicates with inference vars in GAT substs](rust-lang#92917) * On 2022-02-15, [Rework GAT where clause check](rust-lang#93820) * On 2022-02-19, [Only mark projection as ambiguous if GAT substs are constrained](rust-lang#93892) * On 2022-03-03, [Support GATs in Rustdoc](rust-lang#94009) * On 2022-03-06, [Change location of where clause on GATs](rust-lang#90076) * On 2022-05-04, [A shiny future with GATs blog post](https://jackh726.github.io/rust/2022/05/04/a-shiny-future-with-gats.html) * On 2022-05-04, [Stabilization PR](rust-lang#96709)

Stabilize generic associated types Closes #44265 r? `@nikomatsakis` # ⚡ Status of the discussion ⚡ * [x] There have been several serious concerns raised, [summarized here](rust-lang/rust#96709 (comment)). * [x] There has also been a [deep-dive comment](rust-lang/rust#96709 (comment)) explaining some of the "patterns of code" that are enabled by GATs, based on use-cases posted to this thread or on the tracking issue. * [x] We have modeled some aspects of GATs in [a-mir-formality](https://github.com/nikomatsakis/a-mir-formality) to give better confidence in how they will be resolved in the future. [You can read a write-up here](https://github.com/rust-lang/types-team/blob/master/minutes/2022-07-08-implied-bounds-and-wf-checking.md). * [x] The major points of the discussion have been [summarized on the GAT initiative repository](https://rust-lang.github.io/generic-associated-types-initiative/mvp.html). * [x] [FCP has been proposed](rust-lang/rust#96709 (comment)) and we are awaiting final decisions and discussion amidst the relevant team members. # Stabilization proposal This PR proposes the stabilization of `#![feature(generic_associated_types)]`. While there a number of future additions to be made and bugs to be fixed (both discussed below), properly doing these will require significant language design and will ultimately likely be backwards-compatible. Given the overwhelming desire to have some form of generic associated types (GATs) available on stable and the stability of the "simple" uses, stabilizing the current subset of GAT features is almost certainly the correct next step. Tracking issue: #44265 Initiative: https://rust-lang.github.io/generic-associated-types-initiative/ RFC: https://github.com/rust-lang/rfcs/blob/master/text/1598-generic_associated_types.md Version: 1.65 (2022-08-22 => beta, 2022-11-03 => stable). ## Motivation There are a myriad of potential use cases for GATs. Stabilization unblocks probable future language features (e.g. async functions in traits), potential future standard library features (e.g. a `LendingIterator` or some form of `Iterator` with a lifetime generic), and a plethora of user use cases (some of which can be seen just by scrolling through the tracking issue and looking at all the issues linking to it). There are a myriad of potential use cases for GATs. First, there are many users that have chosen to not use GATs primarily because they are not stable (some of which can be seen just by scrolling through the tracking issue and looking at all the issues linking to it). Second, while language feature desugaring isn't *blocked* on stabilization, it gives more confidence on using the feature. Likewise, library features like `LendingIterator` are not necessarily blocked on stabilization to be implemented unstably; however few, if any, public-facing APIs actually use unstable features. This feature has a long history of design, discussion, and developement - the RFC was first introduced roughly 6 years ago. While there are still a number of features left to implement and bugs left to fix, it's clear that it's unlikely those will have backwards-incompatibility concerns. Additionally, the bugs that do exist do not strongly impede the most-common use cases. ## What is stabilized The primary language feature stabilized here is the ability to have generics on associated types, as so. Additionally, where clauses on associated types will now be accepted, regardless if the associated type is generic or not. ```rust trait ATraitWithGATs { type Assoc<'a, T> where T: 'a; } trait ATraitWithoutGATs<'a, T> { type Assoc where T: 'a; } ``` When adding an impl for a trait with generic associated types, the generics for the associated type are copied as well. Note that where clauses are allowed both after the specified type and before the equals sign; however, the latter is a warn-by-default deprecation. ```rust struct X; struct Y; impl ATraitWithGATs for X { type Assoc<'a, T> = &'a T where T: 'a; } impl ATraitWithGATs for Y { type Assoc<'a, T> where T: 'a = &'a T; } ``` To use a GAT in a function, generics are specified on the associated type, as if it was a struct or enum. GATs can also be specified in trait bounds: ```rust fn accepts_gat<'a, T>(t: &'a T) -> T::Assoc<'a, T> where for<'x> T: ATraitWithGATs<Assoc<'a, T> = &'a T> { ... } ``` GATs can also appear in trait methods. However, depending on how they are used, they may confer where clauses on the associated type definition. More information can be found [here](rust-lang/rust#87479). Briefly, where clauses are required when those bounds can be proven in the methods that *construct* the GAT or other associated types that use the GAT in the trait. This allows impls to have maximum flexibility in the types defined for the associated type. To take a relatively simple example: ```rust trait Iterable { type Item<'a>; type Iterator<'a>: Iterator<Item = Self::Item<'a>>; fn iter<'x>(&'x self) -> Self::Iterator<'x>; //^ We know that `Self: 'a` for `Iterator<'a>`, so we require that bound on `Iterator` // `Iterator` uses `Self::Item`, so we also require a `Self: 'a` on `Item` too } ``` A couple well-explained examples are available in a previous [blog post](https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html). ## What isn't stabilized/implemented ### Universal type/const quantification Currently, you can write a bound like `X: for<'a> Trait<Assoc<'a> = &'a ()>`. However, you cannot currently write `for<T> X: Trait<Assoc<T> = T>` or `for<const N> X: Trait<Assoc<N> = [usize; N]>`. Here is an example where this is needed: ```rust trait Foo {} trait Trait { type Assoc<F: Foo>; } trait Trait2: Sized { fn foo<F: Foo, T: Trait<Assoc<F> = F>>(_t: T); } ``` In the above example, the *caller* must specify `F`, which is likely not what is desired. ### Object-safe GATs Unlike non-generic associated types, traits with GATs are not currently object-safe. In other words the following are not allowed: ```rust trait Trait { type Assoc<'a>; } fn foo(t: &dyn for<'a> Trait<Assoc<'a> = &'a ()>) {} //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not allowed let ty: Box<dyn for<'a> Trait<Assoc<'a> = &'a ()>>; //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not allowed ``` ### Higher-kinded types You cannot write currently (and there are no current plans to implement this): ```rust struct Struct<'a> {} fn foo(s: for<'a> Struct<'a>) {} ``` ## Tests There are many tests covering GATs that can be found in `src/test/ui/generic-associated-types`. Here, I'll list (in alphanumeric order) tests highlight some important behavior or contain important patterns. - `./parse/*`: Parsing of GATs in traits and impls, and the trait path with GATs - `./collections-project-default.rs`: Interaction with associated type defaults - `./collections.rs`: The `Collection` pattern - `./const-generics-gat-in-trait-return-type-*.rs`: Const parameters - `./constraint-assoc-type-suggestion.rs`: Emit correct syntax in suggestion - `./cross-crate-bounds.rs`: Ensure we handles bounds across crates the same - `./elided-in-expr-position.rs`: Disallow lifetime elision in return position - `./gat-in-trait-path-undeclared-lifetime.rs`: Ensure we error on undeclared lifetime in trait path - `./gat-in-trait-path.rs`: Base trait path case - `./gat-trait-path-generic-type-arg.rs`: Don't allow shadowing of parameters - `./gat-trait-path-parenthesised-args.rs`: Don't allow paranthesized args in trait path - `./generic-associated-types-where.rs`: Ensure that we require where clauses from trait to be met on impl - `./impl_bounds.rs`: Check that the bounds on GATs in an impl are checked - `./issue-76826.rs`: `Windows` pattern - `./issue-78113-lifetime-mismatch-dyn-trait-box.rs`: Implicit 'static diagnostics - `./issue-84931.rs`: Ensure that we have a where clause on GAT to ensure trait parameter lives long enough - `./issue-87258_a.rs`: Unconstrained opaque type with TAITs - `./issue-87429-2.rs`: Ensure we can use bound vars in the bounds - `./issue-87429-associated-type-default.rs`: Ensure bounds hold with associated type defaults, for both trait and impl - `./issue-87429-specialization.rs`: Check that bounds hold under specialization - `./issue-88595.rs`: Under the outlives lint, we require a bound for both trait and GAT lifetime when trait lifetime is used in function - `./issue-90014.rs`: Lifetime bounds are checked with TAITs - `./issue-91139.rs`: Under migrate mode, but not NLL, we don't capture implied bounds from HRTB lifetimes used in a function and GATs - `./issue-91762.rs`: We used to too eagerly pick param env candidates when normalizing with GATs. We now require explicit parameters specified. - `./issue-95305.rs`: Disallow lifetime elision in trait paths - `./iterable.rs`: `Iterable` pattern - `./method-unsatified-assoc-type-predicate.rs`: Print predicates with GATs correctly in method resolve error - `./missing_lifetime_const.rs`: Ensure we must specify lifetime args (not elidable) - `./missing-where-clause-on-trait.rs`: Ensure we don't allow stricter bounds on impl than trait - `./parameter_number_and_kind_impl.rs`: Ensure paramters on GAT in impl match GAT in trait - `./pointer_family.rs`: `PointerFamily` pattern - `./projection-bound-cycle.rs`: Don't allow invalid cycles to prove bounds - `./self-outlives-lint.rs`: Ensures that an e.g. `Self: 'a` is written on the traits GAT if that bound can be implied from the GAT usage in the trait - `./shadowing.rs`: Don't allow lifetime shadowing in params - `./streaming_iterator.rs`: `StreamingIterator`(`LendingIterator`) pattern - `./trait-objects.rs`: Disallow trait objects for traits with GATs - `./variance_constraints.rs`: Require that GAT substs be invariant ## Remaining bugs and open issues A full list of remaining open issues can be found at: https://github.com/rust-lang/rust/labels/F-generic_associated_types There are some `known-bug` tests in-tree at `src/test/ui/generic-associated-types/bugs`. Here I'll categorize most of those that GAT bugs (or involve a pattern found more with GATs), but not those that include GATs but not a GAT issue in and of itself. (I also won't include issues directly for things listed elsewhere here.) Using the concrete type of a GAT instead of the projection type can give errors, since lifetimes are chosen to be early-bound vs late-bound. - #85533 - #87803 In certain cases, we can run into cycle or overflow errors. This is more generally a problem with associated types. - #87755 - #87758 Bounds on an associatd type need to be proven by an impl, but where clauses need to be proven by the usage. This can lead to confusion when users write one when they mean the other. - #87831 - #90573 We sometimes can't normalize closure signatures fully. Really an asociated types issue, but might happen a bit more frequently with GATs, since more obvious place for HRTB lifetimes. - #88382 When calling a function, we assign types to parameters "too late", after we already try (and fail) to normalize projections. Another associated types issue that might pop up more with GATs. - #88460 - #96230 We don't fully have implied bounds for lifetimes appearing in GAT trait paths, which can lead to unconstrained type errors. - #88526 Suggestion for adding lifetime bounds can suggest unhelpful fixes (`T: 'a` instead of `Self: 'a`), but the next compiler error after making the suggested change is helpful. - #90816 - #92096 - #95268 We can end up requiring that `for<'a> I: 'a` when we really want `for<'a where I: 'a> I: 'a`. This can leave unhelpful errors than effectively can't be satisfied unless `I: 'static`. Requires bigger changes and not only GATs. - #91693 Unlike with non-generic associated types, we don't eagerly normalize with param env candidates. This is intended behavior (for now), to avoid accidentaly stabilizing picking arbitrary impls. - #91762 Some Iterator adapter patterns (namely `filter`) require Polonius or unsafe to work. - #92985 ## Potential Future work ### Universal type/const quantification No work has been done to implement this. There are also some questions around implied bounds. ### Object-safe GATs The intention is to make traits with GATs object-safe. There are some design work to be done around well-formedness rules and general implementation. ### GATified std lib types It would be helpful to either introduce new std lib traits (like `LendingIterator`) or to modify existing ones (adding a `'a` generic to `Iterator::Item`). There also a number of other candidates, like `Index`/`IndexMut` and `Fn`/`FnMut`/`FnOnce`. ### Reduce the need for `for<'a>` Seen [here](rust-lang/rfcs#1598 (comment)). One possible syntax: ```rust trait Iterable { type Iter<'a>: Iterator<Item = Self::Item<'a>>; } fn foo<T>() where T: Iterable, T::Item<let 'a>: Display { } //note the `let`! ``` ### Better implied bounds on higher-ranked things Currently if we have a `type Item<'a> where self: 'a`, and a `for<'a> T: Iterator<Item<'a> = &'a ()`, this requires `for<'a> Self: 'a`. Really, we want `for<'a where T: 'a> ...` There was some mentions of this all the back in the RFC thread [here](rust-lang/rfcs#1598 (comment)). ## Alternatives ### Make generics on associated type in bounds a binder Imagine the bound `for<'a> T: Trait<Item<'a>= &'a ()>`. It might be that `for<'a>` is "too large" and it should instead be `T: Trait<for<'a> Item<'a>= &'a ()>`. Brought up in RFC thread [here](rust-lang/rfcs#1598 (comment)) and in a few places since. Another related question: Is `for<'a>` the right syntax? Maybe `where<'a>`? Also originally found in RFC thread [here](rust-lang/rfcs#1598 (comment)). ### Stabilize lifetime GATs first This has been brought up a few times. The idea is to only allow GATs with lifetime parameters to in initial stabilization. This was probably most useful prior to actual implementation. At this point, lifetimes, types, and consts are all implemented and work. It feels like an arbitrary split without strong reason. ## History * On 2016-04-30, [RFC opened](rust-lang/rfcs#1598) * On 2017-09-02, RFC merged and [tracking issue opened](rust-lang/rust#44265) * On 2017-10-23, [Move Generics from MethodSig to TraitItem and ImplItem](rust-lang/rust#44766) * On 2017-12-01, [Generic Associated Types Parsing & Name Resolution](rust-lang/rust#45904) * On 2017-12-15, [https://github.com/rust-lang/rust/pull/46706](https://github.com/rust-lang/rust/pull/46706) * On 2018-04-23, [Feature gate where clauses on associated types](rust-lang/rust#49368) * On 2018-05-10, [Extend tests for RFC1598 (GAT)](rust-lang/rust#49423) * On 2018-05-24, [Finish implementing GATs (Chalk)](rust-lang/chalk#134) * On 2019-12-21, [Make GATs less ICE-prone](rust-lang/rust#67160) * On 2020-02-13, [fix lifetime shadowing check in GATs](rust-lang/rust#68938) * On 2020-06-20, [Projection bound validation](rust-lang/rust#72788) * On 2020-10-06, [Separate projection bounds and predicates](rust-lang/rust#73905) * On 2021-02-05, [Generic associated types in trait paths](rust-lang/rust#79554) * On 2021-02-06, [Trait objects do not work with generic associated types](rust-lang/rust#81823) * On 2021-04-28, [Make traits with GATs not object safe](rust-lang/rust#84622) * On 2021-05-11, [Improve diagnostics for GATs](rust-lang/rust#82272) * On 2021-07-16, [Make GATs no longer an incomplete feature](rust-lang/rust#84623) * On 2021-07-16, [Replace associated item bound vars with placeholders when projecting](rust-lang/rust#86993) * On 2021-07-26, [GATs: Decide whether to have defaults for `where Self: 'a`](rust-lang/rust#87479) * On 2021-08-25, [Normalize projections under binders](rust-lang/rust#85499) * On 2021-08-03, [The push for GATs stabilization](https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html) * On 2021-08-12, [Detect stricter constraints on gats where clauses in impls vs trait](rust-lang/rust#88336) * On 2021-09-20, [Proposal: Change syntax of where clauses on type aliases](rust-lang/rust#89122) * On 2021-11-06, [Implementation of GATs outlives lint](rust-lang/rust#89970) * On 2021-12-29. [Parse and suggest moving where clauses after equals for type aliases](rust-lang/rust#92118) * On 2022-01-15, [Ignore static lifetimes for GATs outlives lint](rust-lang/rust#92865) * On 2022-02-08, [Don't constrain projection predicates with inference vars in GAT substs](rust-lang/rust#92917) * On 2022-02-15, [Rework GAT where clause check](rust-lang/rust#93820) * On 2022-02-19, [Only mark projection as ambiguous if GAT substs are constrained](rust-lang/rust#93892) * On 2022-03-03, [Support GATs in Rustdoc](rust-lang/rust#94009) * On 2022-03-06, [Change location of where clause on GATs](rust-lang/rust#90076) * On 2022-05-04, [A shiny future with GATs blog post](https://jackh726.github.io/rust/2022/05/04/a-shiny-future-with-gats.html) * On 2022-05-04, [Stabilization PR](rust-lang/rust#96709)

sunjay commented Nov 10, 2017

View reviewed changes

petrochenkov self-assigned this Nov 10, 2017

shepmaster 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. labels Nov 10, 2017

nikomatsakis reviewed Nov 10, 2017

View reviewed changes

petrochenkov reviewed Nov 11, 2017

View reviewed changes

petrochenkov assigned nikomatsakis Nov 11, 2017

nikomatsakis reviewed Nov 14, 2017

View reviewed changes

nikomatsakis requested changes Nov 14, 2017

View reviewed changes

kennytm 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 Nov 14, 2017

sunjay commented Nov 19, 2017

View reviewed changes

sunjay mentioned this pull request Nov 21, 2017

[WIP] Generic Associated Types Name Resolution #46146

Closed

sunjay changed the title ~~Generic Associated Types Parsing~~ Generic Associated Types Parsing & Name Resolution Nov 22, 2017

petrochenkov mentioned this pull request Nov 23, 2017

trait alias infrastructure #45047

Merged

10 tasks

sunjay commented Nov 26, 2017

View reviewed changes

petrochenkov removed their assignment Nov 26, 2017

nikomatsakis approved these changes Nov 29, 2017

View reviewed changes

nikomatsakis and others added 13 commits December 1, 2017 01:26

demonstrate how we can write "successful parse" tests quite easily

e565b5b

Specifically gating generic_associated_types feature on associated Ty…

c2aaba9

…pe declarations

Parsing where clauses correctly and documenting the grammar being parsed

223d091

Preventing moving out of the trait item kind

4a69ce9

Adding type paramter ribs for generic associated types

e0621a1

Renaming MethodRibKind to TraitOrImplItemRibKind and removing its fie…

1c023b3

…ld which was never used. Lifting the HasTypeParameters rib to all trait item kinds and all impl item kinds

Testing and fixes

38c2a73

added must-compile-successfully

3bac9ff

Adding error line so that test passes

cc52e41

Removed FIXME on a line that actually works for some reason...

db4408a

Moved all of the tests over to ui and annotated why they are failing …

fdf6c65

…with appropriate fixme comments

Added case for when impl generic associated type has a where clause

f0ecdfb

Updated generic-associated-types-where stderr

9d5592b

bors merged commit 9d5592b into rust-lang:master Dec 2, 2017

sunjay deleted the gat-parser branch December 2, 2017 02:57

LukasKalbertodt mentioned this pull request Jun 12, 2018

🔬 Tracking issue for generic associated types (GAT) #44265

Closed

28 tasks

estebank mentioned this pull request Aug 1, 2018

rustc doesn't output anything but exits with 101 and doesn't emit any files #52913

Closed

Centril added the F-generic_associated_types `#![feature(generic_associated_types)]` a.k.a. GATs label Aug 5, 2019

jackh726 mentioned this pull request May 4, 2022

Stabilize generic associated types #96709

Merged

5 tasks

Generic Associated Types Parsing & Name Resolution #45904

Generic Associated Types Parsing & Name Resolution #45904

Conversation

sunjay commented Nov 10, 2017 • edited Loading

Notes For Reviewers

sunjay Nov 10, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

petrochenkov Nov 11, 2017 • edited Loading

Choose a reason for hiding this comment

petrochenkov Nov 11, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bors commented Nov 12, 2017

Choose a reason for hiding this comment

nikomatsakis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikomatsakis commented Nov 14, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bors commented Nov 21, 2017

sunjay commented Nov 22, 2017

sunjay commented Nov 22, 2017

bors commented Nov 23, 2017

sunjay Nov 26, 2017 • edited Loading

Choose a reason for hiding this comment

nikomatsakis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikomatsakis commented Nov 29, 2017

bors commented Nov 29, 2017

nikomatsakis commented Nov 30, 2017

arielb1 commented Nov 30, 2017

sunjay commented Dec 1, 2017

nikomatsakis commented Dec 1, 2017

bors commented Dec 1, 2017

bors commented Dec 2, 2017

bors commented Dec 2, 2017

sunjay commented Dec 2, 2017

sunjay commented Nov 10, 2017 •

edited

Loading

sunjay Nov 10, 2017 •

edited

Loading

petrochenkov Nov 11, 2017 •

edited

Loading

petrochenkov Nov 11, 2017 •

edited

Loading

sunjay Nov 26, 2017 •

edited

Loading