🔬 Tracking issue for generic associated types (GAT)

[withoutboats]

This is a tracking issue for generic associated types (rust-lang/rfcs#1598)

Repository

• Detailed tracking information is available at the GAT initiative repository

Unresolved questions:

• GATs: Decide whether to have defaults for where Self: 'a #87479 -- defaults for where Self: 'a
• Proposal: Change syntax of where clauses on type aliases #89122 -- where to put where clauses

Blocking bugs

See also the GATs-blocking tag (the list below should be a superset of that, but its good to double-check).

• lifetime-parametric GATs cause ICEs (with feature(generic_associated_types)) #62521
• Associated type projections don't play well with HRTBs and normalization #30472 No longer blocking
• Pretty printing loses associated type generics and where clauses #67509
• Allow generic associate types in trait paths #67510
• Generic associated types can shadow lifetimes #67512
• Implement type- and const-generic associated types #67513
• GAT's arent typechecked, and can cause UB #68641
• GAT's and broken LLVM #68642
• GAT ICE: use of PlaceRef { local: _0, projection: [] } before def #68643
• GAT ICE: Encountered error Unimplemented selecting `Binder #68644
• GAT ICE: FulfillmentError #68645
• GAT ICE: impl item and trait item have different parameter counts #68648
• GAT ICE: place local already assigned to #68649
• GAT ICE: unsize_thin_ptr: called on bad types #68650
• GAT ICE: codegen_argument #68652
• GAT ICE: unelided lifetime in signature #68653
• GAT ICE: cannot directly store unsized values #68656
• Broken LLVM with GAT #74684
• [nightly] ICE when using GATs with const generics #75415
• ICE when combining GATs and HRTBs #76826
• Internal Compiler Error caused by Generic Associated Types #79768
• Enum variant with GAT field fails to derive Sized #80626 Not GATs specific, not blocking
• Error when inferring a lifetime in return type using GATs #81487
• Bad diagnostics for GATs in trait paths #81801
• defaults on GATs emit an error but function correctlyish #99205

Postponed work

• Trait objects do not work with generic associated types #81823

[nikomatsakis]

Here is a kind of implementation plan I will endeavor to keep updated.

• Step one: add support into the AST and pretty-printing
  • Probably the first step is to start parsing the new forms and to add support for them to the AST.
  • See this comment for more detailed thoughts here.
  • We should be able to write some parsing-only tests and also test the pretty-printer hir
  • When we get to HIR lowering, we can error out if any GAT are present
  • We can also do the feature gate then
• More to come

[nikomatsakis]

Let me start by writing about the AST in more detail. First let's discuss how it works today:

A type Foo: Bar [= Baz]; item in a trait definition is defined by this AST variant. That includes the bounds (Bar) and the (optional) default value Baz. The name is defined in the TraitItem struct.

A type Foo = Bar; item in a trait impl is defined by this AST variant -- that only includes the type Bar, because the Foo etc is defined in the ImplItem struct.

Methods are an interesting case because they can already be made generic. Those generic parameters are declared in the field Generics of the MethodSig structure. This is an instance of the Generics struct.

My take is that the best thing to do would be to "lift" Generics out from methods into the TraitItem (and ImplItem) so that it applies equally to all forms of trait and impl items. For now, we will not support generic constants, I guess, but honestly they probably just fall out from the work we are doing in any case, so they would be a small extension. I think the work will go better if we just plan for them now.

Perhaps a decent first PR would be to just do that change, keeping all other existing functionality the same. That is, we would more Generics into TraitItem (and ImplItem) and out of MethodSig. We would supply an empty Generics for non-methods. We would work through the existing code, plumbing the generics along as needed to make it work.