Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix lifetime shadowing check in GATs #68938

Merged
merged 1 commit into from
Feb 14, 2020

Conversation

basil-cow
Copy link
Contributor

closes #67512

@rust-highfive
Copy link
Collaborator

r? @estebank

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 7, 2020
@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-llvm-7 of your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
2020-02-07T20:44:11.9428782Z ========================== Starting Command Output ===========================
2020-02-07T20:44:11.9431570Z [command]/bin/bash --noprofile --norc /home/vsts/work/_temp/29c9c919-fab2-494f-b768-776ab57020f0.sh
2020-02-07T20:44:11.9562723Z 
2020-02-07T20:44:11.9615424Z ##[section]Finishing: Disable git automatic line ending conversion
2020-02-07T20:44:11.9620361Z ##[section]Starting: Checkout rust-lang/rust@refs/pull/68938/merge to s
2020-02-07T20:44:11.9621709Z Task         : Get sources
2020-02-07T20:44:11.9621742Z Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.
2020-02-07T20:44:11.9621767Z Version      : 1.0.0
2020-02-07T20:44:11.9621792Z Author       : Microsoft
---
2020-02-07T20:44:12.7058706Z ##[command]git remote add origin https://github.com/rust-lang/rust
2020-02-07T20:44:12.7146937Z ##[command]git config gc.auto 0
2020-02-07T20:44:12.7224274Z ##[command]git config --get-all http.https://github.com/rust-lang/rust.extraheader
2020-02-07T20:44:12.7444161Z ##[command]git config --get-all http.proxy
2020-02-07T20:44:12.7451101Z ##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --force --tags --prune --progress --no-recurse-submodules --depth=2 origin +refs/heads/*:refs/remotes/origin/* +refs/pull/68938/merge:refs/remotes/pull/68938/merge
---
2020-02-07T21:33:01.6701042Z .................................................................................................... 1700/9603
2020-02-07T21:33:06.0858940Z .................................................................................................... 1800/9603
2020-02-07T21:33:17.0909596Z .............................i...................................................................... 1900/9603
2020-02-07T21:33:23.5234833Z .................................................................................................... 2000/9603
2020-02-07T21:33:35.8886272Z ...................iiiii............................................................................ 2100/9603
2020-02-07T21:33:45.0588250Z .................................................................................................... 2300/9603
2020-02-07T21:33:47.1901128Z .................................................................................................... 2400/9603
2020-02-07T21:33:51.4876128Z .................................................................................................... 2500/9603
2020-02-07T21:34:09.2340421Z .................................................................................................... 2600/9603
---
2020-02-07T21:36:21.9962580Z .....................................................................i...............i.............. 4900/9603
2020-02-07T21:36:28.5878356Z .................................................................................................... 5000/9603
2020-02-07T21:36:35.3166955Z .................................................................................................... 5100/9603
2020-02-07T21:36:39.1752239Z ............i....................................................................................... 5200/9603
2020-02-07T21:36:48.4287213Z ......................................................................................ii.ii........i 5300/9603
2020-02-07T21:36:54.9560936Z ........................i........................................................................... 5500/9603
2020-02-07T21:37:01.9023071Z .................................................................................................... 5600/9603
2020-02-07T21:37:08.9994124Z ..........................................................................i......................... 5700/9603
2020-02-07T21:37:15.3728941Z .................................................................................................... 5800/9603
2020-02-07T21:37:15.3728941Z .................................................................................................... 5800/9603
2020-02-07T21:37:20.7812609Z .................................................................................................... 5900/9603
2020-02-07T21:37:29.3172081Z .................................................................ii...i..ii...........i............. 6000/9603
2020-02-07T21:37:46.8239420Z .................................................................................................... 6200/9603
2020-02-07T21:37:52.9430732Z .................................................................................................... 6300/9603
2020-02-07T21:37:52.9430732Z .................................................................................................... 6300/9603
2020-02-07T21:37:59.2581605Z .............................................................................................i..ii.. 6400/9603
2020-02-07T21:38:25.1842760Z .................................................................................................... 6600/9603
2020-02-07T21:38:33.5615227Z ................................................................................i................... 6700/9603
2020-02-07T21:38:35.2290244Z .................................................................................................... 6800/9603
2020-02-07T21:38:37.0351770Z .......................................................................................i............ 6900/9603
---
2020-02-07T21:40:01.1002740Z .................................................................................................... 7600/9603
2020-02-07T21:40:05.0835161Z .................................................................................................... 7700/9603
2020-02-07T21:40:09.7360962Z .................................................................................................... 7800/9603
2020-02-07T21:40:17.2605673Z .................................................................................................... 7900/9603
2020-02-07T21:40:24.1401008Z ..................................................iiiiiii.i......................................... 8000/9603
2020-02-07T21:40:32.2681823Z ..........................................................................................i......i.. 8100/9603
2020-02-07T21:40:40.5524007Z .................................................................................................... 8300/9603
2020-02-07T21:40:53.2056172Z .................................................................................................... 8400/9603
2020-02-07T21:41:00.5081782Z .................................................................................................... 8500/9603
2020-02-07T21:41:06.5769175Z .................................................................................................... 8600/9603
---
2020-02-07T21:42:35.0197725Z 16 
2020-02-07T21:42:35.0198104Z + error[E0496]: lifetime name `'a` shadows a lifetime name that is already in scope
2020-02-07T21:42:35.0198434Z +   --> $DIR/shadowing.rs:6:14
2020-02-07T21:42:35.0198590Z +    |
2020-02-07T21:42:35.0198887Z + LL | trait Shadow<'a> {
2020-02-07T21:42:35.0199211Z +    |              -- first declared here
2020-02-07T21:42:35.0199392Z + LL |     //FIXME(#44265): The lifetime parameter shadowing should cause an error.
2020-02-07T21:42:35.0199701Z + LL |     type Bar<'a>;
2020-02-07T21:42:35.0200026Z +    |              ^^ lifetime 'a already in scope
2020-02-07T21:42:35.0200524Z + error[E0496]: lifetime name `'a` shadows a lifetime name that is already in scope
2020-02-07T21:42:35.0201481Z +   --> $DIR/shadowing.rs:15:14
2020-02-07T21:42:35.0201670Z +    |
2020-02-07T21:42:35.0201670Z +    |
2020-02-07T21:42:35.0201999Z + LL | impl<'a> NoShadow<'a> for &'a u32 {
2020-02-07T21:42:35.0202313Z +    |      -- first declared here
2020-02-07T21:42:35.0202491Z + LL |     //FIXME(#44265): The lifetime parameter shadowing should cause an error.
2020-02-07T21:42:35.0202778Z + LL |     type Bar<'a> = i32;
2020-02-07T21:42:35.0203099Z +    |              ^^ lifetime 'a already in scope
2020-02-07T21:42:35.0203584Z 17 error: type-generic associated types are not yet implemented
2020-02-07T21:42:35.0203908Z 18   --> $DIR/shadowing.rs:19:5
2020-02-07T21:42:35.0204093Z 19    |
2020-02-07T21:42:35.0204203Z 
2020-02-07T21:42:35.0204203Z 
2020-02-07T21:42:35.0204320Z 30    |
2020-02-07T21:42:35.0204780Z 31    = note: for more information, see ***/issues/44265
2020-02-07T21:42:35.0205253Z - error: aborting due to 4 previous errors
2020-02-07T21:42:35.0205435Z + error: aborting due to 6 previous errors
2020-02-07T21:42:35.0205574Z 34 
2020-02-07T21:42:35.0205887Z - For more information about this error, try `rustc --explain E0403`.
2020-02-07T21:42:35.0205887Z - For more information about this error, try `rustc --explain E0403`.
2020-02-07T21:42:35.0206069Z + Some errors have detailed explanations: E0403, E0496.
2020-02-07T21:42:35.0206381Z + For more information about an error, try `rustc --explain E0403`.
2020-02-07T21:42:35.0206553Z 36 
2020-02-07T21:42:35.0206658Z 
2020-02-07T21:42:35.0206763Z 
2020-02-07T21:42:35.0206885Z The actual stderr differed from the expected stderr.
2020-02-07T21:42:35.0207432Z Actual stderr saved to /checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/generic-associated-types/shadowing/shadowing.stderr
2020-02-07T21:42:35.0207863Z To update references, rerun the tests and pass the `--bless` flag
2020-02-07T21:42:35.0208297Z To only update this specific test, also pass `--test-args generic-associated-types/shadowing.rs`
2020-02-07T21:42:35.0208591Z error: 1 errors occurred comparing output.
2020-02-07T21:42:35.0208884Z status: exit code: 1
2020-02-07T21:42:35.0208884Z status: exit code: 1
2020-02-07T21:42:35.0209694Z command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/ui/generic-associated-types/shadowing.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/generic-associated-types/shadowing" "-Crpath" "-O" "-Cdebuginfo=0" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/generic-associated-types/shadowing/auxiliary" "-A" "unused"
2020-02-07T21:42:35.0210239Z ------------------------------------------
2020-02-07T21:42:35.0210385Z 
2020-02-07T21:42:35.0210721Z ------------------------------------------
2020-02-07T21:42:35.0210882Z stderr:
2020-02-07T21:42:35.0210882Z stderr:
2020-02-07T21:42:35.0211200Z ------------------------------------------
2020-02-07T21:42:35.0211602Z error[E0403]: the name `T` is already used for a generic parameter in this item's generic parameters
2020-02-07T21:42:35.0211965Z   --> /checkout/src/test/ui/generic-associated-types/shadowing.rs:19:14
2020-02-07T21:42:35.0212162Z    |
2020-02-07T21:42:35.0212289Z LL | trait ShadowT<T> {
2020-02-07T21:42:35.0212591Z    |               - first use of `T`
2020-02-07T21:42:35.0212769Z LL |     type Bar<T>;
2020-02-07T21:42:35.0212896Z    |              ^ already used
2020-02-07T21:42:35.0213382Z error[E0403]: the name `T` is already used for a generic parameter in this item's generic parameters
2020-02-07T21:42:35.0213755Z   --> /checkout/src/test/ui/generic-associated-types/shadowing.rs:30:14
2020-02-07T21:42:35.0213915Z    |
2020-02-07T21:42:35.0213915Z    |
2020-02-07T21:42:35.0214062Z LL | impl<T> NoShadowT<T> for Option<T> {
2020-02-07T21:42:35.0214359Z    |      - first use of `T`
2020-02-07T21:42:35.0214537Z LL |     type Bar<T> = i32;
2020-02-07T21:42:35.0214908Z    |              ^ already used
2020-02-07T21:42:35.0216977Z error[E0496]: lifetime name `'a` shadows a lifetime name that is already in scope
2020-02-07T21:42:35.0218381Z   --> /checkout/src/test/ui/generic-associated-types/shadowing.rs:6:14
2020-02-07T21:42:35.0219182Z    |
2020-02-07T21:42:35.0220163Z LL | trait Shadow<'a> {
2020-02-07T21:42:35.0220163Z LL | trait Shadow<'a> {
2020-02-07T21:42:35.0221530Z    |              -- first declared here
2020-02-07T21:42:35.0222284Z LL |     //FIXME(#44265): The lifetime parameter shadowing should cause an error.
2020-02-07T21:42:35.0223287Z LL |     type Bar<'a>;
2020-02-07T21:42:35.0224334Z    |              ^^ lifetime 'a already in scope
2020-02-07T21:42:35.0225583Z error[E0496]: lifetime name `'a` shadows a lifetime name that is already in scope
2020-02-07T21:42:35.0225954Z   --> /checkout/src/test/ui/generic-associated-types/shadowing.rs:15:14
2020-02-07T21:42:35.0226113Z    |
2020-02-07T21:42:35.0226113Z    |
2020-02-07T21:42:35.0249417Z LL | impl<'a> NoShadow<'a> for &'a u32 {
2020-02-07T21:42:35.0299746Z    |      -- first declared here
2020-02-07T21:42:35.0299853Z LL |     //FIXME(#44265): The lifetime parameter shadowing should cause an error.
2020-02-07T21:42:35.0300385Z LL |     type Bar<'a> = i32;
2020-02-07T21:42:35.0300593Z    |              ^^ lifetime 'a already in scope
2020-02-07T21:42:35.0300821Z error: type-generic associated types are not yet implemented
2020-02-07T21:42:35.0301058Z   --> /checkout/src/test/ui/generic-associated-types/shadowing.rs:19:5
2020-02-07T21:42:35.0301099Z    |
2020-02-07T21:42:35.0301166Z LL |     type Bar<T>;
2020-02-07T21:42:35.0301166Z LL |     type Bar<T>;
2020-02-07T21:42:35.0301221Z    |     ^^^^^^^^^^^^
2020-02-07T21:42:35.0301419Z    |
2020-02-07T21:42:35.0301776Z    = note: for more information, see ***/issues/44265
2020-02-07T21:42:35.0302053Z error: type-generic associated types are not yet implemented
2020-02-07T21:42:35.0302280Z   --> /checkout/src/test/ui/generic-associated-types/shadowing.rs:25:5
2020-02-07T21:42:35.0302339Z    |
2020-02-07T21:42:35.0302339Z    |
2020-02-07T21:42:35.0302485Z LL |     type Bar<U>; // OK
2020-02-07T21:42:35.0302575Z    |
2020-02-07T21:42:35.0302575Z    |
2020-02-07T21:42:35.0303040Z    = note: for more information, see ***/issues/44265
2020-02-07T21:42:35.0303110Z error: aborting due to 6 previous errors
2020-02-07T21:42:35.0303152Z 
2020-02-07T21:42:35.0303189Z Some errors have detailed explanations: E0403, E0496.
2020-02-07T21:42:35.0303719Z For more information about an error, try `rustc --explain E0403`.
---
2020-02-07T21:42:35.0306212Z thread 'main' panicked at 'Some tests failed', src/tools/compiletest/src/main.rs:348:22
2020-02-07T21:42:35.0306258Z note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
2020-02-07T21:42:35.0306283Z 
2020-02-07T21:42:35.0306320Z 
2020-02-07T21:42:35.0307495Z command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/ui" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "ui" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-7/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "7.0.0\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
2020-02-07T21:42:35.0307699Z 
2020-02-07T21:42:35.0307723Z 
2020-02-07T21:42:35.0307760Z failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
2020-02-07T21:42:35.0307817Z Build completed unsuccessfully in 0:52:53
2020-02-07T21:42:35.0307817Z Build completed unsuccessfully in 0:52:53
2020-02-07T21:42:35.0307854Z == clock drift check ==
2020-02-07T21:42:35.0314529Z   local time: Fri Feb  7 21:42:35 UTC 2020
2020-02-07T21:42:35.1952748Z   network time: Fri, 07 Feb 2020 21:42:35 GMT
2020-02-07T21:42:35.1953640Z == end clock drift check ==
2020-02-07T21:42:35.5761318Z 
2020-02-07T21:42:35.5842315Z ##[error]Bash exited with code '1'.
2020-02-07T21:42:35.5872091Z ##[section]Finishing: Run build
2020-02-07T21:42:35.5896666Z ##[section]Starting: Checkout rust-lang/rust@refs/pull/68938/merge to s
2020-02-07T21:42:35.5898146Z Task         : Get sources
2020-02-07T21:42:35.5898181Z Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.
2020-02-07T21:42:35.5898217Z Version      : 1.0.0
2020-02-07T21:42:35.5898264Z Author       : Microsoft
2020-02-07T21:42:35.5898264Z Author       : Microsoft
2020-02-07T21:42:35.5898299Z Help         : [More Information](https://go.microsoft.com/fwlink/?LinkId=798199)
2020-02-07T21:42:35.5898336Z ==============================================================================
2020-02-07T21:42:35.9604000Z Cleaning any cached credential from repository: rust-lang/rust (GitHub)
2020-02-07T21:42:35.9633266Z ##[section]Finishing: Checkout rust-lang/rust@refs/pull/68938/merge to s
2020-02-07T21:42:35.9724129Z Cleaning up task key
2020-02-07T21:42:35.9724739Z Start cleaning up orphan processes.
2020-02-07T21:42:35.9813097Z Terminate orphan process: pid (3726) (python)
2020-02-07T21:42:36.0009204Z ##[section]Finishing: Finalize Job

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@basil-cow basil-cow force-pushed the gat_lifetime_shadowing branch from 863a953 to 953f6ec Compare February 7, 2020 22:13
@estebank
Copy link
Contributor

estebank commented Feb 7, 2020

This change would need at least a crater run. Ideally we would change check_lifetime_params to be either E0496 or an allowable lint for older code. The code changes as they are look reasonable to me if we didn't have to care about backwards compatibility though.

@estebank estebank added I-nominated T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 7, 2020
@estebank
Copy link
Contributor

estebank commented Feb 7, 2020

@bors try

@bors
Copy link
Contributor

bors commented Feb 7, 2020

⌛ Trying commit 953f6ec with merge 26ab07b...

bors added a commit that referenced this pull request Feb 7, 2020
fix lifetime shadowing check in GATs

closes #67512
@basil-cow
Copy link
Contributor Author

basil-cow commented Feb 7, 2020

Sure, I'll make it an warn by default lint then if it's coming from a GAT

@basil-cow
Copy link
Contributor Author

Just curious: at what point does it become a hard error then?

@bors
Copy link
Contributor

bors commented Feb 8, 2020

☀️ Try build successful - checks-azure
Build commit: 26ab07b (26ab07b6be5f6cefd9de500c297bff67da2c4691)

@matthewjasper
Copy link
Contributor

@estebank what stable code is this a breaking change for?

@estebank
Copy link
Contributor

@matthewjasper you're right, I blanked on the fact that this is nightly only.

@estebank
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Feb 13, 2020

📌 Commit 953f6ec has been approved by estebank

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 13, 2020
@estebank estebank added relnotes Marks issues that should be documented in the release notes of the next release. and removed I-nominated labels Feb 13, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Feb 13, 2020
…=estebank

fix lifetime shadowing check in GATs

closes rust-lang#67512
bors added a commit that referenced this pull request Feb 13, 2020
Rollup of 9 pull requests

Successful merges:

 - #68728 (parse: merge `fn` syntax + cleanup item parsing)
 - #68938 (fix lifetime shadowing check in GATs)
 - #69057 (expand: misc cleanups and simplifications)
 - #69108 (Use HirId in TraitCandidate.)
 - #69125 (Add comment to SGX entry code)
 - #69126 (miri: fix exact_div)
 - #69127 (Enable use after scope detection in the new LLVM pass manager)
 - #69135 (Spelling error "represening" to "representing")
 - #69141 (Don't error on network failures)

Failed merges:

r? @ghost
@bors bors merged commit 953f6ec into rust-lang:master Feb 14, 2020
@jackh726 jackh726 mentioned this pull request May 4, 2022
5 tasks
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 13, 2022
…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)
calebcartwright pushed a commit to calebcartwright/rustfmt that referenced this pull request Jan 24, 2023
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)
RalfJung pushed a commit to RalfJung/rust-analyzer that referenced this pull request Apr 20, 2024
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)
RalfJung pushed a commit to RalfJung/rust-analyzer that referenced this pull request Apr 27, 2024
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relnotes Marks issues that should be documented in the release notes of the next release. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Generic associated types can shadow lifetimes
5 participants