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

Don't require associated types with Self: Sized bounds in dyn Trait objects #112319

Merged

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Jun 5, 2023

Trait objects require all associated types to be specified, even if the associated type has an explicit where Self: Sized bound. The following snippet does not compile on master, but does with this PR.

fn _assert_is_object_safe(_: &dyn Foo) {}

pub trait Foo {
    type Bar where Self: Sized;
}

In contrast, if a Self: Sized bound is added to a method, the methodjust isn't callable on trait objects, but the trait can be made object safe just fine.

fn _assert_is_object_safe(_: &dyn Foo) {}

pub trait Foo {
    fn foo() where Self: Sized;
}

This PR closes this inconsistency (though it still exists for associated constants).

Additionally this PR adds a new lint that informs users they can remove associated type bounds from their trait objects if those associated type bounds have a where Self: Sized bound, and are thus useless.

r? @compiler-errors

@rustbot
Copy link
Collaborator

rustbot commented Jun 5, 2023

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @compiler-errors (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 5, 2023
@oli-obk
Copy link
Contributor Author

oli-obk commented Jun 5, 2023

@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jun 5, 2023
@bors
Copy link
Contributor

bors commented Jun 5, 2023

⌛ Trying commit 661b143ebaaee94d37cf44bd71f78007f2caf799 with merge 90c098e28583990068dbac5e390c33c77a2578e5...

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Jun 5, 2023

☀️ Try build successful - checks-actions
Build commit: 90c098e28583990068dbac5e390c33c77a2578e5 (90c098e28583990068dbac5e390c33c77a2578e5)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (90c098e28583990068dbac5e390c33c77a2578e5): comparison URL.

Overall result: ❌ regressions - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.5% [0.4%, 1.0%] 5
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
4.0% [3.0%, 5.0%] 2
Improvements ✅
(primary)
-1.1% [-1.4%, -0.8%] 4
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -1.1% [-1.4%, -0.8%] 4

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
2.2% [2.2%, 2.2%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 646.24s -> 646.543s (0.05%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jun 5, 2023
@compiler-errors
Copy link
Member

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 5, 2023
@oli-obk oli-obk added A-associated-items Area: Associated items (types, constants & functions) T-lang Relevant to the language team, which will review and decide on the PR/issue. needs-fcp This change is insta-stable, so needs a completed FCP to proceed. T-types Relevant to the types team, which will review and decide on the PR/issue. and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 6, 2023
@oli-obk oli-obk force-pushed the assoc_ty_sized_bound_for_object_safety2 branch from 661b143 to 476de46 Compare June 14, 2023 08:45
@rust-log-analyzer

This comment has been minimized.

@oli-obk oli-obk force-pushed the assoc_ty_sized_bound_for_object_safety2 branch from 476de46 to 79fc300 Compare June 14, 2023 09:18
@rust-log-analyzer

This comment has been minimized.

@oli-obk oli-obk force-pushed the assoc_ty_sized_bound_for_object_safety2 branch from 79fc300 to f282208 Compare June 14, 2023 11:07
Comment on lines +10 to +12
//~^ WARN: unnecessary associated type bound for not object safe associated type
//~| WARN: unnecessary associated type bound for not object safe associated type
//~| WARN: unnecessary associated type bound for not object safe associated type
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These get deduplicated for users

@oli-obk
Copy link
Contributor Author

oli-obk commented Jun 15, 2023

@rfcbot fcp merge

I am starting this FCP for both T-types and T-lang. While I believe closing such gaps is entirely in the purview of T-types, considering that I want to close further such gaps, I would like T-lang to chime in to say whether they agree with my assessment and are fine with just getting pinged in the future, but not included in the FCPs.

The summary of what is being stabilized here is all documented in the main post.

@rfcbot
Copy link

rfcbot commented Jun 15, 2023

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

No concerns currently listed.

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

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

@rustbot rustbot added this to the 1.72.0 milestone Jul 5, 2023
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (99f7d36): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
3.3% [3.3%, 3.3%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-3.0% [-3.4%, -2.6%] 2
All ❌✅ (primary) - - 0

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 655.25s -> 655.506s (0.04%)

@oli-obk oli-obk deleted the assoc_ty_sized_bound_for_object_safety2 branch July 5, 2023 12:44
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Jul 6, 2023
1715173329 added a commit to 1715173329/packages-official that referenced this pull request Aug 26, 2023
Version 1.72.0 (2023-08-24)
==========================

Language
--------

- [Replace const eval limit by a lint and add an exponential backoff warning](rust-lang/rust#103877)
- [expand: Change how `#![cfg(FALSE)]` behaves on crate root](rust-lang/rust#110141)
- [Stabilize inline asm for LoongArch64](rust-lang/rust#111235)
- [Uplift `clippy::undropped_manually_drops` lint](rust-lang/rust#111530)
- [Uplift `clippy::invalid_utf8_in_unchecked` lint](rust-lang/rust#111543)
- [Uplift `clippy::cast_ref_to_mut` lint](rust-lang/rust#111567)
- [Uplift `clippy::cmp_nan` lint](rust-lang/rust#111818)
- [resolve: Remove artificial import ambiguity errors](rust-lang/rust#112086)
- [Don't require associated types with Self: Sized bounds in `dyn Trait` objects](rust-lang/rust#112319)

Compiler
--------

- [Remember names of `cfg`-ed out items to mention them in diagnostics](rust-lang/rust#109005)
- [Support for native WASM exceptions](rust-lang/rust#111322)
- [Add support for NetBSD/aarch64-be (big-endian arm64).](rust-lang/rust#111326)
- [Write to stdout if `-` is given as output file](rust-lang/rust#111626)
- [Force all native libraries to be statically linked when linking a static binary](rust-lang/rust#111698)
- [Add Tier 3 support for `loongarch64-unknown-none*`](rust-lang/rust#112310)
- [Prevent `.eh_frame` from being emitted for `-C panic=abort`](rust-lang/rust#112403)
- [Support 128-bit enum variant in debuginfo codegen](rust-lang/rust#112474)
- [compiler: update solaris/illumos to enable tsan support.](rust-lang/rust#112039)

Refer to Rust's [platform support page][platform-support-doc]
for more information on Rust's tiered platform support.

Libraries
---------

- [Document memory orderings of `thread::{park, unpark}`](rust-lang/rust#99587)
- [io: soften ‘at most one write attempt’ requirement in io::Write::write](rust-lang/rust#107200)
- [Specify behavior of HashSet::insert](rust-lang/rust#107619)
- [Relax implicit `T: Sized` bounds on `BufReader<T>`, `BufWriter<T>` and `LineWriter<T>`](rust-lang/rust#111074)
- [Update runtime guarantee for `select_nth_unstable`](rust-lang/rust#111974)
- [Return `Ok` on kill if process has already exited](rust-lang/rust#112594)
- [Implement PartialOrd for `Vec`s over different allocators](rust-lang/rust#112632)
- [Use 128 bits for TypeId hash](rust-lang/rust#109953)
- [Don't drain-on-drop in DrainFilter impls of various collections.](rust-lang/rust#104455)
- [Make `{Arc,Rc,Weak}::ptr_eq` ignore pointer metadata](rust-lang/rust#106450)

Rustdoc
-------

- [Allow whitespace as path separator like double colon](rust-lang/rust#108537)
- [Add search result item types after their name](rust-lang/rust#110688)
- [Search for slices and arrays by type with `[]`](rust-lang/rust#111958)
- [Clean up type unification and "unboxing"](rust-lang/rust#112233)

Stabilized APIs
---------------

- [`impl<T: Send> Sync for mpsc::Sender<T>`](https://doc.rust-lang.org/nightly/std/sync/mpsc/struct.Sender.html#impl-Sync-for-Sender%3CT%3E)
- [`impl TryFrom<&OsStr> for &str`](https://doc.rust-lang.org/nightly/std/primitive.str.html#impl-TryFrom%3C%26'a+OsStr%3E-for-%26'a+str)
- [`String::leak`](https://doc.rust-lang.org/nightly/alloc/string/struct.String.html#method.leak)

These APIs are now stable in const contexts:

- [`CStr::from_bytes_with_nul`](https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)
- [`CStr::to_bytes`](https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)
- [`CStr::to_bytes_with_nul`](https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)
- [`CStr::to_str`](https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)

Cargo
-----

- Enable `-Zdoctest-in-workspace` by default. When running each documentation
  test, the working directory is set to the root directory of the package the
  test belongs to.
  [docs](https://doc.rust-lang.org/nightly/cargo/commands/cargo-test.html#working-directory-of-tests)
  [openwrt#12221](rust-lang/cargo#12221)
  [openwrt#12288](rust-lang/cargo#12288)
- Add support of the "default" keyword to reset previously set `build.jobs`
  parallelism back to the default.
  [openwrt#12222](rust-lang/cargo#12222)

Compatibility Notes
-------------------

- [Alter `Display` for `Ipv6Addr` for IPv4-compatible addresses](rust-lang/rust#112606)
- Cargo changed feature name validation check to a hard error. The warning was
  added in Rust 1.49. These extended characters aren't allowed on crates.io, so
  this should only impact users of other registries, or people who don't publish
  to a registry.
  [openwrt#12291](rust-lang/cargo#12291)

Refreshed patches.

Signed-off-by: Tianling Shen <[email protected]>
1715173329 added a commit to 1715173329/packages-official that referenced this pull request Aug 26, 2023
Version 1.72.0 (2023-08-24)
==========================

Language
--------
- [Replace const eval limit by a lint and add an exponential backoff warning](rust-lang/rust#103877)
- [expand: Change how `#![cfg(FALSE)]` behaves on crate root](rust-lang/rust#110141)
- [Stabilize inline asm for LoongArch64](rust-lang/rust#111235)
- [Uplift `clippy::undropped_manually_drops` lint](rust-lang/rust#111530)
- [Uplift `clippy::invalid_utf8_in_unchecked` lint](rust-lang/rust#111543)
- [Uplift `clippy::cast_ref_to_mut` lint](rust-lang/rust#111567)
- [Uplift `clippy::cmp_nan` lint](rust-lang/rust#111818)
- [resolve: Remove artificial import ambiguity errors](rust-lang/rust#112086)
- [Don't require associated types with Self: Sized bounds in `dyn Trait` objects](rust-lang/rust#112319)

Compiler
--------
- [Remember names of `cfg`-ed out items to mention them in diagnostics](rust-lang/rust#109005)
- [Support for native WASM exceptions](rust-lang/rust#111322)
- [Add support for NetBSD/aarch64-be (big-endian arm64).](rust-lang/rust#111326)
- [Write to stdout if `-` is given as output file](rust-lang/rust#111626)
- [Force all native libraries to be statically linked when linking a static binary](rust-lang/rust#111698)
- [Add Tier 3 support for `loongarch64-unknown-none*`](rust-lang/rust#112310)
- [Prevent `.eh_frame` from being emitted for `-C panic=abort`](rust-lang/rust#112403)
- [Support 128-bit enum variant in debuginfo codegen](rust-lang/rust#112474)
- [compiler: update solaris/illumos to enable tsan support.](rust-lang/rust#112039)

Refer to Rust's [platform support page][platform-support-doc]
for more information on Rust's tiered platform support.

Libraries
---------
- [Document memory orderings of `thread::{park, unpark}`](rust-lang/rust#99587)
- [io: soften ‘at most one write attempt’ requirement in io::Write::write](rust-lang/rust#107200)
- [Specify behavior of HashSet::insert](rust-lang/rust#107619)
- [Relax implicit `T: Sized` bounds on `BufReader<T>`, `BufWriter<T>` and `LineWriter<T>`](rust-lang/rust#111074)
- [Update runtime guarantee for `select_nth_unstable`](rust-lang/rust#111974)
- [Return `Ok` on kill if process has already exited](rust-lang/rust#112594)
- [Implement PartialOrd for `Vec`s over different allocators](rust-lang/rust#112632)
- [Use 128 bits for TypeId hash](rust-lang/rust#109953)
- [Don't drain-on-drop in DrainFilter impls of various collections.](rust-lang/rust#104455)
- [Make `{Arc,Rc,Weak}::ptr_eq` ignore pointer metadata](rust-lang/rust#106450)

Rustdoc
-------
- [Allow whitespace as path separator like double colon](rust-lang/rust#108537)
- [Add search result item types after their name](rust-lang/rust#110688)
- [Search for slices and arrays by type with `[]`](rust-lang/rust#111958)
- [Clean up type unification and "unboxing"](rust-lang/rust#112233)

Stabilized APIs
---------------
- [`impl<T: Send> Sync for mpsc::Sender<T>`](https://doc.rust-lang.org/nightly/std/sync/mpsc/struct.Sender.html#impl-Sync-for-Sender%3CT%3E)
- [`impl TryFrom<&OsStr> for &str`](https://doc.rust-lang.org/nightly/std/primitive.str.html#impl-TryFrom%3C%26'a+OsStr%3E-for-%26'a+str)
- [`String::leak`](https://doc.rust-lang.org/nightly/alloc/string/struct.String.html#method.leak)

These APIs are now stable in const contexts:

- [`CStr::from_bytes_with_nul`](https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)
- [`CStr::to_bytes`](https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)
- [`CStr::to_bytes_with_nul`](https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)
- [`CStr::to_str`](https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)

Cargo
-----
- Enable `-Zdoctest-in-workspace` by default. When running each documentation
  test, the working directory is set to the root directory of the package the
  test belongs to.
  [docs](https://doc.rust-lang.org/nightly/cargo/commands/cargo-test.html#working-directory-of-tests)
  [openwrt#12221](rust-lang/cargo#12221)
  [openwrt#12288](rust-lang/cargo#12288)
- Add support of the "default" keyword to reset previously set `build.jobs`
  parallelism back to the default.
  [openwrt#12222](rust-lang/cargo#12222)

Compatibility Notes
-------------------
- [Alter `Display` for `Ipv6Addr` for IPv4-compatible addresses](rust-lang/rust#112606)
- Cargo changed feature name validation check to a hard error. The warning was
  added in Rust 1.49. These extended characters aren't allowed on crates.io, so
  this should only impact users of other registries, or people who don't publish
  to a registry.
  [openwrt#12291](rust-lang/cargo#12291)

Refreshed patches.

Signed-off-by: Tianling Shen <[email protected]>
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Sep 4, 2023
…fety, r=oli-obk

Do not require associated types with Self: Sized to uphold bounds when confirming object candidate

RPITITs and associated types that have `Self: Sized` bounds are opted out of the `dyn Trait` well-formedness check that happens during confirmation. This ensures that we can actually *use* `dyn Trait`s that have associated types that, e.g., have GATs and RPITITs and other naughty things as long as those are opted-out of object safety via a `Self: Sized` bound.

Fixes rust-lang#115464

This seems like a natural part of rust-lang#112319 (comment), and I don't think needs re-litigation.

r? `@oli-obk`
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 5, 2023
…ty, r=oli-obk

Do not require associated types with Self: Sized to uphold bounds when confirming object candidate

RPITITs and associated types that have `Self: Sized` bounds are opted out of the `dyn Trait` well-formedness check that happens during confirmation. This ensures that we can actually *use* `dyn Trait`s that have associated types that, e.g., have GATs and RPITITs and other naughty things as long as those are opted-out of object safety via a `Self: Sized` bound.

Fixes rust-lang#115464

This seems like a natural part of rust-lang#112319 (comment), and I don't think needs re-litigation.

r? `@oli-obk`
RalfJung pushed a commit to RalfJung/miri that referenced this pull request Sep 6, 2023
…-obk

Do not require associated types with Self: Sized to uphold bounds when confirming object candidate

RPITITs and associated types that have `Self: Sized` bounds are opted out of the `dyn Trait` well-formedness check that happens during confirmation. This ensures that we can actually *use* `dyn Trait`s that have associated types that, e.g., have GATs and RPITITs and other naughty things as long as those are opted-out of object safety via a `Self: Sized` bound.

Fixes #115464

This seems like a natural part of rust-lang/rust#112319 (comment), and I don't think needs re-litigation.

r? `@oli-obk`
jefferyto pushed a commit to jefferyto/openwrt-packages that referenced this pull request Sep 21, 2023
Version 1.72.0 (2023-08-24)
==========================

Language
--------
- [Replace const eval limit by a lint and add an exponential backoff warning](rust-lang/rust#103877)
- [expand: Change how `#![cfg(FALSE)]` behaves on crate root](rust-lang/rust#110141)
- [Stabilize inline asm for LoongArch64](rust-lang/rust#111235)
- [Uplift `clippy::undropped_manually_drops` lint](rust-lang/rust#111530)
- [Uplift `clippy::invalid_utf8_in_unchecked` lint](rust-lang/rust#111543)
- [Uplift `clippy::cast_ref_to_mut` lint](rust-lang/rust#111567)
- [Uplift `clippy::cmp_nan` lint](rust-lang/rust#111818)
- [resolve: Remove artificial import ambiguity errors](rust-lang/rust#112086)
- [Don't require associated types with Self: Sized bounds in `dyn Trait` objects](rust-lang/rust#112319)

Compiler
--------
- [Remember names of `cfg`-ed out items to mention them in diagnostics](rust-lang/rust#109005)
- [Support for native WASM exceptions](rust-lang/rust#111322)
- [Add support for NetBSD/aarch64-be (big-endian arm64).](rust-lang/rust#111326)
- [Write to stdout if `-` is given as output file](rust-lang/rust#111626)
- [Force all native libraries to be statically linked when linking a static binary](rust-lang/rust#111698)
- [Add Tier 3 support for `loongarch64-unknown-none*`](rust-lang/rust#112310)
- [Prevent `.eh_frame` from being emitted for `-C panic=abort`](rust-lang/rust#112403)
- [Support 128-bit enum variant in debuginfo codegen](rust-lang/rust#112474)
- [compiler: update solaris/illumos to enable tsan support.](rust-lang/rust#112039)

Refer to Rust's [platform support page][platform-support-doc]
for more information on Rust's tiered platform support.

Libraries
---------
- [Document memory orderings of `thread::{park, unpark}`](rust-lang/rust#99587)
- [io: soften ‘at most one write attempt’ requirement in io::Write::write](rust-lang/rust#107200)
- [Specify behavior of HashSet::insert](rust-lang/rust#107619)
- [Relax implicit `T: Sized` bounds on `BufReader<T>`, `BufWriter<T>` and `LineWriter<T>`](rust-lang/rust#111074)
- [Update runtime guarantee for `select_nth_unstable`](rust-lang/rust#111974)
- [Return `Ok` on kill if process has already exited](rust-lang/rust#112594)
- [Implement PartialOrd for `Vec`s over different allocators](rust-lang/rust#112632)
- [Use 128 bits for TypeId hash](rust-lang/rust#109953)
- [Don't drain-on-drop in DrainFilter impls of various collections.](rust-lang/rust#104455)
- [Make `{Arc,Rc,Weak}::ptr_eq` ignore pointer metadata](rust-lang/rust#106450)

Rustdoc
-------
- [Allow whitespace as path separator like double colon](rust-lang/rust#108537)
- [Add search result item types after their name](rust-lang/rust#110688)
- [Search for slices and arrays by type with `[]`](rust-lang/rust#111958)
- [Clean up type unification and "unboxing"](rust-lang/rust#112233)

Stabilized APIs
---------------
- [`impl<T: Send> Sync for mpsc::Sender<T>`](https://doc.rust-lang.org/nightly/std/sync/mpsc/struct.Sender.html#impl-Sync-for-Sender%3CT%3E)
- [`impl TryFrom<&OsStr> for &str`](https://doc.rust-lang.org/nightly/std/primitive.str.html#impl-TryFrom%3C%26'a+OsStr%3E-for-%26'a+str)
- [`String::leak`](https://doc.rust-lang.org/nightly/alloc/string/struct.String.html#method.leak)

These APIs are now stable in const contexts:

- [`CStr::from_bytes_with_nul`](https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)
- [`CStr::to_bytes`](https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)
- [`CStr::to_bytes_with_nul`](https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)
- [`CStr::to_str`](https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)

Cargo
-----
- Enable `-Zdoctest-in-workspace` by default. When running each documentation
  test, the working directory is set to the root directory of the package the
  test belongs to.
  [docs](https://doc.rust-lang.org/nightly/cargo/commands/cargo-test.html#working-directory-of-tests)
  [openwrt#12221](rust-lang/cargo#12221)
  [openwrt#12288](rust-lang/cargo#12288)
- Add support of the "default" keyword to reset previously set `build.jobs`
  parallelism back to the default.
  [openwrt#12222](rust-lang/cargo#12222)

Compatibility Notes
-------------------
- [Alter `Display` for `Ipv6Addr` for IPv4-compatible addresses](rust-lang/rust#112606)
- Cargo changed feature name validation check to a hard error. The warning was
  added in Rust 1.49. These extended characters aren't allowed on crates.io, so
  this should only impact users of other registries, or people who don't publish
  to a registry.
  [openwrt#12291](rust-lang/cargo#12291)

Refreshed patches.

Signed-off-by: Tianling Shen <[email protected]>
(cherry picked from commit 846ee0b)
Signed-off-by: Jeffery To <[email protected]>
BKPepe pushed a commit to openwrt/packages that referenced this pull request Sep 21, 2023
Version 1.72.0 (2023-08-24)
==========================

Language
--------
- [Replace const eval limit by a lint and add an exponential backoff warning](rust-lang/rust#103877)
- [expand: Change how `#![cfg(FALSE)]` behaves on crate root](rust-lang/rust#110141)
- [Stabilize inline asm for LoongArch64](rust-lang/rust#111235)
- [Uplift `clippy::undropped_manually_drops` lint](rust-lang/rust#111530)
- [Uplift `clippy::invalid_utf8_in_unchecked` lint](rust-lang/rust#111543)
- [Uplift `clippy::cast_ref_to_mut` lint](rust-lang/rust#111567)
- [Uplift `clippy::cmp_nan` lint](rust-lang/rust#111818)
- [resolve: Remove artificial import ambiguity errors](rust-lang/rust#112086)
- [Don't require associated types with Self: Sized bounds in `dyn Trait` objects](rust-lang/rust#112319)

Compiler
--------
- [Remember names of `cfg`-ed out items to mention them in diagnostics](rust-lang/rust#109005)
- [Support for native WASM exceptions](rust-lang/rust#111322)
- [Add support for NetBSD/aarch64-be (big-endian arm64).](rust-lang/rust#111326)
- [Write to stdout if `-` is given as output file](rust-lang/rust#111626)
- [Force all native libraries to be statically linked when linking a static binary](rust-lang/rust#111698)
- [Add Tier 3 support for `loongarch64-unknown-none*`](rust-lang/rust#112310)
- [Prevent `.eh_frame` from being emitted for `-C panic=abort`](rust-lang/rust#112403)
- [Support 128-bit enum variant in debuginfo codegen](rust-lang/rust#112474)
- [compiler: update solaris/illumos to enable tsan support.](rust-lang/rust#112039)

Refer to Rust's [platform support page][platform-support-doc]
for more information on Rust's tiered platform support.

Libraries
---------
- [Document memory orderings of `thread::{park, unpark}`](rust-lang/rust#99587)
- [io: soften ‘at most one write attempt’ requirement in io::Write::write](rust-lang/rust#107200)
- [Specify behavior of HashSet::insert](rust-lang/rust#107619)
- [Relax implicit `T: Sized` bounds on `BufReader<T>`, `BufWriter<T>` and `LineWriter<T>`](rust-lang/rust#111074)
- [Update runtime guarantee for `select_nth_unstable`](rust-lang/rust#111974)
- [Return `Ok` on kill if process has already exited](rust-lang/rust#112594)
- [Implement PartialOrd for `Vec`s over different allocators](rust-lang/rust#112632)
- [Use 128 bits for TypeId hash](rust-lang/rust#109953)
- [Don't drain-on-drop in DrainFilter impls of various collections.](rust-lang/rust#104455)
- [Make `{Arc,Rc,Weak}::ptr_eq` ignore pointer metadata](rust-lang/rust#106450)

Rustdoc
-------
- [Allow whitespace as path separator like double colon](rust-lang/rust#108537)
- [Add search result item types after their name](rust-lang/rust#110688)
- [Search for slices and arrays by type with `[]`](rust-lang/rust#111958)
- [Clean up type unification and "unboxing"](rust-lang/rust#112233)

Stabilized APIs
---------------
- [`impl<T: Send> Sync for mpsc::Sender<T>`](https://doc.rust-lang.org/nightly/std/sync/mpsc/struct.Sender.html#impl-Sync-for-Sender%3CT%3E)
- [`impl TryFrom<&OsStr> for &str`](https://doc.rust-lang.org/nightly/std/primitive.str.html#impl-TryFrom%3C%26'a+OsStr%3E-for-%26'a+str)
- [`String::leak`](https://doc.rust-lang.org/nightly/alloc/string/struct.String.html#method.leak)

These APIs are now stable in const contexts:

- [`CStr::from_bytes_with_nul`](https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)
- [`CStr::to_bytes`](https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)
- [`CStr::to_bytes_with_nul`](https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)
- [`CStr::to_str`](https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)

Cargo
-----
- Enable `-Zdoctest-in-workspace` by default. When running each documentation
  test, the working directory is set to the root directory of the package the
  test belongs to.
  [docs](https://doc.rust-lang.org/nightly/cargo/commands/cargo-test.html#working-directory-of-tests)
  [#12221](rust-lang/cargo#12221)
  [#12288](rust-lang/cargo#12288)
- Add support of the "default" keyword to reset previously set `build.jobs`
  parallelism back to the default.
  [#12222](rust-lang/cargo#12222)

Compatibility Notes
-------------------
- [Alter `Display` for `Ipv6Addr` for IPv4-compatible addresses](rust-lang/rust#112606)
- Cargo changed feature name validation check to a hard error. The warning was
  added in Rust 1.49. These extended characters aren't allowed on crates.io, so
  this should only impact users of other registries, or people who don't publish
  to a registry.
  [#12291](rust-lang/cargo#12291)

Refreshed patches.

Signed-off-by: Tianling Shen <[email protected]>
(cherry picked from commit 846ee0b)
Signed-off-by: Jeffery To <[email protected]>
wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request Sep 24, 2023
Pkgsrc changes:
 * Adjust patches and cargo checksums to new versions.

Upstream changes:

Version 1.72.0 (2023-08-24)
==========================

Language
--------

- [Replace const eval limit by a lint and add an exponential backoff warning]
  (rust-lang/rust#103877)
- [expand: Change how `#![cfg(FALSE)]` behaves on crate root]
  (rust-lang/rust#110141)
- [Stabilize inline asm for LoongArch64]
  (rust-lang/rust#111235)
- [Uplift `clippy::undropped_manually_drops` lint]
  (rust-lang/rust#111530)
- [Uplift `clippy::invalid_utf8_in_unchecked` lint]
  (rust-lang/rust#111543)
- [Uplift `clippy::cast_ref_to_mut` lint]
  (rust-lang/rust#111567)
- [Uplift `clippy::cmp_nan` lint]
  (rust-lang/rust#111818)
- [resolve: Remove artificial import ambiguity errors]
  (rust-lang/rust#112086)
- [Don't require associated types with Self: Sized bounds in `dyn
  Trait` objects]
  (rust-lang/rust#112319)

Compiler
--------

- [Remember names of `cfg`-ed out items to mention them in diagnostics]
  (rust-lang/rust#109005)
- [Support for native WASM exceptions]
  (rust-lang/rust#111322)
- [Add support for NetBSD/aarch64-be (big-endian arm64).]
  (rust-lang/rust#111326)
- [Write to stdout if `-` is given as output file]
  (rust-lang/rust#111626)
- [Force all native libraries to be statically linked when linking
  a static binary]
  (rust-lang/rust#111698)
- [Add Tier 3 support for `loongarch64-unknown-none*`]
  (rust-lang/rust#112310)
- [Prevent `.eh_frame` from being emitted for `-C panic=abort`]
  (rust-lang/rust#112403)
- [Support 128-bit enum variant in debuginfo codegen]
  (rust-lang/rust#112474)
- [compiler: update solaris/illumos to enable tsan support.]
  (rust-lang/rust#112039)

Refer to Rust's [platform support page][platform-support-doc]
for more information on Rust's tiered platform support.

Libraries
---------

- [Document memory orderings of `thread::{park, unpark}`]
  (rust-lang/rust#99587)
- [io: soften â<80><98>at most one write attemptâ<80><99>
   requirement in io::Write::write]
  (rust-lang/rust#107200)
- [Specify behavior of HashSet::insert]
  (rust-lang/rust#107619)
- [Relax implicit `T: Sized` bounds on `BufReader<T>`, `BufWriter<T>`
  and `LineWriter<T>`]
  (rust-lang/rust#111074)
- [Update runtime guarantee for `select_nth_unstable`]
  (rust-lang/rust#111974)
- [Return `Ok` on kill if process has already exited]
  (rust-lang/rust#112594)
- [Implement PartialOrd for `Vec`s over different allocators]
  (rust-lang/rust#112632)
- [Use 128 bits for TypeId hash]
  (rust-lang/rust#109953)
- [Don't drain-on-drop in DrainFilter impls of various collections.]
  (rust-lang/rust#104455)
- [Make `{Arc,Rc,Weak}::ptr_eq` ignore pointer metadata]
  (rust-lang/rust#106450)

Rustdoc
-------

- [Allow whitespace as path separator like double colon]
  (rust-lang/rust#108537)
- [Add search result item types after their name]
  (rust-lang/rust#110688)
- [Search for slices and arrays by type with `[]`]
  (rust-lang/rust#111958)
- [Clean up type unification and "unboxing"]
  (rust-lang/rust#112233)

Stabilized APIs
---------------

- [`impl<T: Send> Sync for mpsc::Sender<T>`]
  (https://doc.rust-lang.org/nightly/std/sync/mpsc/struct.Sender.html#impl-Sync-for-Sender%3CT%3E)
- [`impl TryFrom<&OsStr> for &str`]
  (https://doc.rust-lang.org/nightly/std/primitive.str.html#impl-TryFrom%3C%26'a+OsStr%3E-for-%26'a+str)
- [`String::leak`]
  (https://doc.rust-lang.org/nightly/alloc/string/struct.String.html#method.leak)

These APIs are now stable in const contexts:

- [`CStr::from_bytes_with_nul`]
  (https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)
- [`CStr::to_bytes`]
  (https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)
- [`CStr::to_bytes_with_nul`]
  (https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)
- [`CStr::to_str`]
  (https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)

Cargo
-----

- Enable `-Zdoctest-in-workspace` by default. When running each documentation
  test, the working directory is set to the root directory of the package the
  test belongs to.
  [docs](https://doc.rust-lang.org/nightly/cargo/commands/cargo-test.html#working-directory-of-tests)
  [#12221](rust-lang/cargo#12221)
  [#12288](rust-lang/cargo#12288)
- Add support of the "default" keyword to reset previously set `build.jobs`
  parallelism back to the default.
  [#12222](rust-lang/cargo#12222)

Compatibility Notes
-------------------

- [Alter `Display` for `Ipv6Addr` for IPv4-compatible addresses]
  (rust-lang/rust#112606)
- Cargo changed feature name validation check to a hard error. The
  warning was added in Rust 1.49. These extended characters aren't
  allowed on crates.io, so this should only impact users of other
  registries, or people who don't publish to a registry.
  [#12291](rust-lang/cargo#12291)
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 14, 2023
…jackh726

Stabilize `async fn` and return-position `impl Trait` in trait

# Stabilization report

This report proposes the stabilization of `#![feature(return_position_impl_trait_in_trait)]` ([RPITIT][RFC 3425]) and `#![feature(async_fn_in_trait)]` ([AFIT][RFC 3185]). These are both long awaited features that increase the expressiveness of the Rust language and trait system.

Closes rust-lang#91611

[RFC 3185]: https://rust-lang.github.io/rfcs/3185-static-async-fn-in-trait.html
[RFC 3425]: https://rust-lang.github.io/rfcs/3425-return-position-impl-trait-in-traits.html

## Updates from thread

The thread has covered two major concerns:

* [Given that we don't have RTN, what should we stabilize?](rust-lang#115822 (comment)) -- proposed resolution is [adding a lint](rust-lang#115822 (comment)) and [careful messaging](rust-lang#115822 (comment))
* [Interaction between outlives bounds and capture semantics](rust-lang#115822 (comment)) -- This is fixable in a forwards-compatible way via rust-lang#116040, and also eventually via ATPIT.

## Stabilization Summary

This stabilization allows the following examples to work.

### Example of return-position `impl Trait` in trait definition

```rust
trait Bar {
    fn bar(self) -> impl Send;
}
```

This declares a trait method that returns *some* type that implements `Send`.  It's similar to writing the following using an associated type, except that the associated type is anonymous.

```rust
trait Bar {
    type _0: Send;
    fn bar(self) -> Self::_0;
}
```

### Example of return-position `impl Trait` in trait implementation

```rust
impl Bar for () {
    fn bar(self) -> impl Send {}
}
```

This defines a method implementation that returns an opaque type, just like [RPIT][RFC 1522] does, except that all in-scope lifetimes are captured in the opaque type (as is already true for `async fn` and as is expected to be true for RPIT in Rust Edition 2024), as described below.

[RFC 1522]: https://rust-lang.github.io/rfcs/1522-conservative-impl-trait.html

### Example of `async fn` in trait

```rust
trait Bar {
    async fn bar(self);
}

impl Bar for () {
    async fn bar(self) {}
}
```

This declares a trait method that returns *some* [`Future`](https://doc.rust-lang.org/core/future/trait.Future.html) and a corresponding method implementation.  This is equivalent to writing the following using RPITIT.

```rust
use core::future::Future;

trait Bar {
    fn bar(self) -> impl Future<Output = ()>;
}

impl Bar for () {
    fn bar(self) -> impl Future<Output = ()> { async {} }
}
```

The desirability of this desugaring being available is part of why RPITIT and AFIT are being proposed for stabilization at the same time.

## Motivation

Long ago, Rust added [RPIT][RFC 1522] and [`async`/`await`][RFC 2394].  These are major features that are widely used in the ecosystem.  However, until now, these feature could not be used in *traits* and trait implementations.  This left traits as a kind of second-class citizen of the language.  This stabilization fixes that.

[RFC 2394]: https://rust-lang.github.io/rfcs/2394-async_await.html

### `async fn` in trait

Async/await allows users to write asynchronous code much easier than they could before. However, it doesn't play nice with other core language features that make Rust the great language it is, like traits. Support for `async fn` in traits has been long anticipated and was not added before due to limitations in the compiler that have now been lifted.

`async fn` in traits will unblock a lot of work in the ecosystem and the standard library. It is not currently possible to write a trait that is implemented using `async fn`. The workarounds that exist are undesirable because they require allocation and dynamic dispatch, and any trait that uses them will become obsolete once native `async fn` in trait is stabilized.

We also have ample evidence that there is demand for this feature from the [`async-trait` crate][async-trait], which emulates the feature using dynamic dispatch. The async-trait crate is currently the rust-lang#5 async crate on crates.io ranked by recent downloads, receiving over 78M all-time downloads. According to a [recent analysis][async-trait-analysis], 4% of all crates use the `#[async_trait]` macro it provides, representing 7% of all function and method signatures in trait definitions on crates.io. We think this is a *lower bound* on demand for the feature, because users are unlikely to use `#[async_trait]` on public traits on crates.io for the reasons already given.

[async-trait]: https://crates.io/crates/async-trait
[async-trait-analysis]: https://rust-lang.zulipchat.com/#narrow/stream/315482-t-compiler.2Fetc.2Fopaque-types/topic/RPIT.20capture.20rules.20.28capturing.20everything.29/near/389496292

### Return-position `impl Trait` in trait

`async fn` always desugars to a function that returns `impl Future`.

```rust!
async fn foo() -> i32 { 100 }

// Equivalent to:
fn foo() -> impl Future<Output = i32> { async { 100 } }
```

All `async fn`s today can be rewritten this way. This is useful because it allows adding behavior that runs at the time of the function call, before the first `.await` on the returned future.

In the spirit of supporting the same set of features on `async fn` in traits that we do outside of traits, it makes sense to stabilize this as well. As described by the [RPITIT RFC][rpitit-rfc], this includes the ability to mix and match the equivalent forms in traits and their corresponding impls:

```rust!
trait Foo {
    async fn foo(self) -> i32;
}

// Can be implemented as:
impl Foo for MyType {
    fn foo(self) -> impl Future<Output = i32> {
        async { 100 }
    }
}
```

Return-position `impl Trait` in trait is useful for cases beyond async, just as regular RPIT is. As a simple example, the RFC showed an alternative way of writing the `IntoIterator` trait with one fewer associated type.

```rust!
trait NewIntoIterator {
    type Item;
    fn new_into_iter(self) -> impl Iterator<Item = Self::Item>;
}

impl<T> NewIntoIterator for Vec<T> {
    type Item = T;
    fn new_into_iter(self) -> impl Iterator<Item = T> {
        self.into_iter()
    }
}
```

[rpitit-rfc]: https://rust-lang.github.io/rfcs/3425-return-position-impl-trait-in-traits.html

## Major design decisions

This section describes the major design decisions that were reached after the RFC was accepted:

- EDIT: Lint against async fn in trait definitions

    - Until the [send bound problem](https://smallcultfollowing.com/babysteps/blog/2023/02/01/async-trait-send-bounds-part-1-intro/) is resolved, the use of `async fn` in trait definitions could lead to a bad experience for people using work-stealing executors (by far the most popular choice). However, there are significant use cases for which the current support is all that is needed (single-threaded executors, such as those used in embedded use cases, as well as thread-per-core setups). We are prioritizing serving users well over protecting people from misuse, and therefore, we opt to stabilize the full range of functionality; however, to help steer people correctly, we are will issue a warning on the use of `async fn` in trait definitions that advises users about the limitations. (See [this summary comment](rust-lang#115822 (comment)) for the details of the concern, and [this comment](rust-lang#115822 (comment)) for more details about the reasoning that led to this conclusion.)

- Capture rules:

    - The RFC's initial capture rules for lifetimes in impls/traits were found to be imprecisely precise and to introduce various inconsistencies. After much discussion, the decision was reached to make `-> impl Trait` in traits/impls capture *all* in-scope parameters, including both lifetimes and types. This is a departure from the behavior of RPITs in other contexts; an RFC is currently being authored to change the behavior of RPITs in other contexts in a future edition.

    - Major discussion links:

        - [Lang team design meeting from 2023-07-26](https://hackmd.io/sFaSIMJOQcuwCdnUvCxtuQ?view)

- Refinement:

    - The [refinement RFC] initially proposed that impl signatures that are more specific than their trait are not allowed unless the `#[refine]` attribute was included, but left it as an open question how to implement this. The stabilized proposal is that it is not a hard error to omit `#[refine]`, but there is a lint which fires if the impl's return type is more precise than the trait. This greatly simplified the desugaring and implementation while still achieving the original goal of ensuring that users do not accidentally commit to a more specific return type than they intended.

    - Major discussion links:

        - [Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/.60.23.5Brefine.5D.60.20as.20a.20lint)

[refinement RFC]: https://rust-lang.github.io/rfcs/3245-refined-impls.html

## What is stabilized

### Async functions in traits and trait implementations

* `async fn` are now supported in traits and trait implementations.
* Associated functions in traits that are `async` may have default bodies.

### Return-position impl trait in traits and trait implementations

* Return-position `impl Trait`s are now supported in traits and trait implementations.
    * Return-position `impl Trait` in implementations are treated like regular return-position `impl Trait`s, and therefore behave according to the same inference rules for hidden type inference and well-formedness.
* Associated functions in traits that name return-position `impl Trait`s may have default bodies.
* Implementations may provide either concrete types or `impl Trait` for each corresponding `impl Trait` in the trait method signature.

For a detailed exploration of the technical implementation of return-position `impl Trait` in traits, see [the dev guide](https://rustc-dev-guide.rust-lang.org/return-position-impl-trait-in-trait.html).

### Mixing `async fn` in trait and return-position `impl Trait` in trait

A trait function declaration that is `async fn ..() -> T` may be satisfied by an implementation function that returns `impl Future<Output = T>`, or vice versa.

```rust
trait Async {
    async fn hello();
}

impl Async for () {
    fn hello() -> impl Future<Output = ()> {
        async {}
    }
}

trait RPIT {
    fn hello() -> impl Future<Output = String>;
}

impl RPIT for () {
    async fn hello() -> String {
        "hello".to_string()
    }
}
```

### Return-position `impl Trait` in traits and trait implementations capture all in-scope lifetimes

Described above in "major design decisions".

### Return-position `impl Trait` in traits are "always revealing"

When a trait uses `-> impl Trait` in return position, it logically desugars to an associated type that represents the return (the actual implementation in the compiler is different, as described below). The value of this associated type is determined by the actual return type written in the impl; if the impl also uses `-> impl Trait` as the return type, then the value of the associated type is an opaque type scoped to the impl method (similar to what you would get when calling an inherent function returning `-> impl Trait`). As with any associated type, the value of this special associated type can be revealed by the compiler if the compiler can figure out what impl is being used.

For example, given this trait:

```rust
trait AsDebug {
    fn as_debug(&self) -> impl Debug;
}
```

A function working with the trait generically is only able to see that the return value is `Debug`:

```rust
fn foo<T: AsDebug>(t: &T) {
    let u = t.as_debug();
    println!("{}", u); // ERROR: `u` is not known to implement `Display`
}
```

But if a function calls `as_debug` on a known type (say, `u32`), it may be able to resolve the return type more specifically, if that implementation specifies a concrete type as well:

```rust
impl AsDebug for u32 {
    fn as_debug(&self) -> u32 {
        *self
    }
}

fn foo(t: &u32) {
    let u: u32 = t.as_debug(); // OK!
    println!("{}",  t.as_debug()); // ALSO OK (since `u32: Display`).
}
```

The return type used in the impl therefore represents a **semver binding** promise from the impl author that the return type of `<u32 as AsDebug>::as_debug` will not change. This could come as a surprise to users, who might expect that they are free to change the return type to any other type that implements `Debug`. To address this, we include a [`refining_impl_trait` lint](rust-lang#115582) that warns if the impl uses a specific type -- the `impl AsDebug for u32` above, for example, would toggle the lint.

The lint message explains what is going on and encourages users to `allow` the lint to indicate that they meant to refine the return type:

```rust
impl AsDebug for u32 {
    #[allow(refining_impl_trait)]
    fn as_debug(&self) -> u32 {
        *self
    }
}
```

[RFC rust-lang#3245](rust-lang/rfcs#3245) proposed a new attribute, `#[refine]`, that could also be used to "opt-in" to refinements like this (and which would then silence the lint). That RFC is not currently implemented -- the `#[refine]` attribute is also expected to reveal other details from the signature and has not yet been fully implemented.

### Return-position `impl Trait` and `async fn` in traits are opted-out of object safety checks when the parent function has `Self: Sized`

```rust
trait IsObjectSafe {
    fn rpit() -> impl Sized where Self: Sized;
    async fn afit() where Self: Sized;
}
```

Traits that mention return-position `impl Trait` or `async fn` in trait when the associated function includes a `Self: Sized` bound will remain object safe. That is because the associated function that defines them will be opted-out of the vtable of the trait, and the associated types will be unnameable from any trait object.

This can alternatively be seen as a consequence of rust-lang#112319 (comment) and the desugaring of return-position `impl Trait` in traits to associated types which inherit the where-clauses of the associated function that defines them.

## What isn't stabilized (aka, potential future work)

### Dynamic dispatch

As stabilized, traits containing RPITIT and AFIT are **not dyn compatible**. This means that you cannot create `dyn Trait` objects from them and can only use static dispatch. The reason for this limitation is that dynamic dispatch support for RPITIT and AFIT is more complex than static dispatch, as described on the [async fundamentals page](https://rust-lang.github.io/async-fundamentals-initiative/evaluation/challenges/dyn_traits.html). The primary challenge to using `dyn Trait` in today's Rust is that **`dyn Trait` today must list the values of all associated types**. This means you would have to write `dyn for<'s> Trait<Foo<'s> = XXX>` where `XXX` is the future type defined by the impl, such as `F_A`. This is not only verbose (or impossible), it also uniquely ties the `dyn Trait` to a particular impl, defeating the whole point of `dyn Trait`.

The precise design for handling dynamic dispatch is not yet determined. Top candidates include:

- [callee site selection][], in which we permit unsized return values so that the return type for an `-> impl Foo` method be can be `dyn Foo`, but then users must specify the type of wide pointer at the call-site in some fashion.

- [`dyn*`][], where we create a built-in encapsulation of a "wide pointer" and map the associated type corresponding to an RPITIT to the corresponding `dyn*` type (`dyn*` itself is not exposed to users as a type in this proposal, though that could be a future extension).

[callee site selection]: https://smallcultfollowing.com/babysteps/blog/2022/09/21/dyn-async-traits-part-9-callee-site-selection/

[`dyn*`]: https://smallcultfollowing.com/babysteps/blog/2022/03/29/dyn-can-we-make-dyn-sized/

### Where-clause bounds on return-position `impl Trait` in traits or async futures (RTN/ART)

One limitation of async fn in traits and RPITIT as stabilized is that there is no way for users to write code that adds additional bounds beyond those listed in the `-> impl Trait`. The most common example is wanting to write a generic function that requires that the future returned from an `async fn` be `Send`:

```rust
trait Greet {
    async fn greet(&self);
}

fn greet_in_parallel<G: Greet>(g: &G) {
    runtime::spawn(async move {
        g.greet().await; //~ ERROR: future returned by `greet` may not be `Send`
    })
}
```

Currently, since the associated types added for the return type are anonymous, there is no where-clause that could be added to make this code compile.

There have been various proposals for how to address this problem (e.g., [return type notation][rtn] or having an annotation to give a name to the associated type), but we leave the selection of one of those mechanisms to future work.

[rtn]: https://smallcultfollowing.com/babysteps/blog/2023/02/13/return-type-notation-send-bounds-part-2/

In the meantime, there are workarounds that one can use to address this problem, listed below.

#### Require all futures to be `Send`

For many users, the trait may only ever be used with `Send` futures, in which case one can write an explicit `impl Future + Send`:

```rust
trait Greet {
    fn greet(&self) -> impl Future<Output = ()> + Send;
}
```

The nice thing about this is that it is still compatible with using `async fn` in the trait impl. In the async working group case studies, we found that this could work for the [builder provider API](https://rust-lang.github.io/async-fundamentals-initiative/evaluation/case-studies/builder-provider-api.html). This is also the default approach used by the `#[async_trait]` crate which, as we have noted, has seen widespread adoption.

#### Avoid generics

This problem only applies when the `Self` type is generic. If the `Self` type is known, then the precise return type from an `async fn` is revealed, and the `Send` bound can be inferred thanks to auto-trait leakage. Even in cases where generics may appear to be required, it is sometimes possible to rewrite the code to avoid them. The [socket handler refactor](https://rust-lang.github.io/async-fundamentals-initiative/evaluation/case-studies/socket-handler.html) case study provides one such example.

### Unify capture behavior for `-> impl Trait` in inherent methods and traits

As stabilized, the capture behavior for `-> impl Trait` in a trait (whether as part of an async fn or a RPITIT) captures all types and lifetimes, whereas the existing behavior for inherent methods only captures types and lifetimes that are explicitly referenced. Capturing all lifetimes in traits was necessary to avoid various surprising inconsistencies; the expressed intent of the lang team is to extend that behavior so that we also capture all lifetimes in inherent methods, which would create more consistency and also address a common source of user confusion, but that will have to happen over the 2024 edition. The RFC is in progress. Should we opt not to accept that RFC, we can bring the capture behavior for `-> impl Trait` into alignment in other ways as part of the 2024 edition.

### `impl_trait_projections`

Orthgonal to `async_fn_in_trait` and `return_position_impl_trait_in_trait`, since it can be triggered on stable code. This will be stabilized separately in [rust-lang#115659](rust-lang#115659).

<details>
If we try to write this code without `impl_trait_projections`, we will get an error:

```rust
#![feature(async_fn_in_trait)]

trait Foo {
    type Error;
    async fn foo(&mut self) -> Result<(), Self::Error>;
}

impl<T: Foo> Foo for &mut T {
    type Error = T::Error;
    async fn foo(&mut self) -> Result<(), Self::Error> {
        T::foo(self).await
    }
}
```

The error relates to the use of `Self` in a trait impl when the self type has a lifetime. It can be worked around by rewriting the impl not to use `Self`:

```rust
#![feature(async_fn_in_trait)]

trait Foo {
    type Error;
    async fn foo(&mut self) -> Result<(), Self::Error>;
}

impl<T: Foo> Foo for &mut T {
    type Error = T::Error;
    async fn foo(&mut self) -> Result<(), <&mut T as Foo>::Error> {
        T::foo(self).await
    }
}
```
</details>

## Tests

Tests are generally organized between return-position `impl Trait` and `async fn` in trait, when the distinction matters.
* RPITIT: https://github.com/rust-lang/rust/tree/master/tests/ui/impl-trait/in-trait
* AFIT: https://github.com/rust-lang/rust/tree/master/tests/ui/async-await/in-trait

## Remaining bugs and open issues

* rust-lang#112047: Indirection introduced by `async fn` and return-position `impl Trait` in traits may hide cycles in opaque types, causing overflow errors that can only be discovered by monomorphization.
* rust-lang#111105 - `async fn` in trait is susceptible to issues with checking auto traits on futures' generators, like regular `async`. This is a manifestation of rust-lang#110338.
    * This was deemed not blocking because fixing it is forwards-compatible, and regular `async` is subject to the same issues.
* rust-lang#104689: `async fn` and return-position `impl Trait` in trait requires the late-bound lifetimes in a trait and impl function signature to be equal.
    * This can be relaxed in the future with a smarter lexical region resolution algorithm.
* rust-lang#102527: Nesting return-position `impl Trait` in trait deeply may result in slow compile times.
    * This has only been reported once, and can be fixed in the future.
* rust-lang#108362: Inference between return types and generics of a function may have difficulties when there's an `.await`.
    * This isn't related to AFIT (rust-lang#108362 (comment)) -- using traits does mean that there's possibly easier ways to hit it.
* rust-lang#112626: Because `async fn` and return-position `impl Trait` in traits lower to associated types, users may encounter strange behaviors when implementing circularly dependent traits.
    * This is not specific to RPITIT, and is a limitation of associated types: rust-lang#112626 (comment)
* **(Nightly)** rust-lang#108309: `async fn` and return-position `impl Trait` in trait do not support specialization. This was deemed not blocking, since it can be fixed in the future (e.g. rust-lang#108321) and specialization is a nightly feature.

#### (Nightly) Return type notation bugs

RTN is not being stabilized here, but there are some interesting outstanding bugs. None of them are blockers for AFIT/RPITIT, but I'm noting them for completeness.

<details>

* rust-lang#109924 is a bug that occurs when a higher-ranked trait bound has both inference variables and associated types. This is pre-existing -- RTN just gives you a more convenient way of producing them. This should be fixed by the new trait solver.
* rust-lang#109924 is a manifestation of a more general issue with `async` and auto-trait bounds: rust-lang#110338. RTN does not cause this issue, just allows us to put `Send` bounds on the anonymous futures that we have in traits.
* rust-lang#112569 is a bug similar to associated type bounds, where nested bounds are not implied correctly.

</details>

## Alternatives

### Do nothing

We could choose not to stabilize these features. Users that can use the `#[async_trait]` macro would continue to do so. Library maintainers would continue to avoid async functions in traits, potentially blocking the stable release of many useful crates.

### Stabilize `impl Trait` in associated type instead

AFIT and RPITIT solve the problem of returning unnameable types from trait methods. It is also possible to solve this by using another unstable feature, `impl Trait` in an associated type. Users would need to define an associated type in both the trait and trait impl:

```rust!
trait Foo {
    type Fut<'a>: Future<Output = i32> where Self: 'a;
    fn foo(&self) -> Self::Fut<'_>;
}

impl Foo for MyType {
    type Fut<'a> where Self: 'a = impl Future<Output = i32>;
    fn foo(&self) -> Self::Fut<'_> {
        async { 42 }
    }
}
```

This also has the advantage of allowing generic code to bound the associated type. However, it is substantially less ergonomic than either `async fn` or `-> impl Future`, and users still expect to be able to use those features in traits. **Even if this feature were stable, we would still want to stabilize AFIT and RPITIT.**

That said, we can have both. `impl Trait` in associated types is desireable because it can be used in existing traits with explicit associated types, among other reasons. We *should* stabilize this feature once it is ready, but that's outside the scope of this proposal.

### Use the old capture semantics for RPITIT

We could choose to make the capture rules for RPITIT consistent with the existing rules for RPIT. However, there was strong consensus in a recent [lang team meeting](https://hackmd.io/sFaSIMJOQcuwCdnUvCxtuQ?view) that we should *change* these rules, and furthermore that new features should adopt the new rules.

This is consistent with the tenet in RFC 3085 of favoring ["Uniform behavior across editions"](https://rust-lang.github.io/rfcs/3085-edition-2021.html#uniform-behavior-across-editions) when possible. It greatly reduces the complexity of the feature by not requiring us to answer, or implement, the design questions that arise out of the interaction between the current capture rules and traits. This reduction in complexity – and eventual technical debt – is exactly in line with the motivation listed in the aforementioned RFC.

### Make refinement a hard error

Refinement (`refining_impl_trait`) is only a concern for library authors, and therefore doesn't really warrant making into a deny-by-default warning or an error.

Additionally, refinement is currently checked via a lint that compares bounds in the `impl Trait`s in the trait and impl syntactically. This is good enough for a warning that can be opted-out, but not if this were a hard error, which would ideally be implemented using fully semantic, implicational logic. This was implemented (rust-lang#111931), but also is an unnecessary burden on the type system for little pay-off.

## History

- Dec 7, 2021: [RFC rust-lang#3185: Static async fn in traits](https://rust-lang.github.io/rfcs/3185-static-async-fn-in-trait.html) merged
- Sep 9, 2022: [Initial implementation](rust-lang#101224) of AFIT and RPITIT landed
- Jun 13, 2023: [RFC rust-lang#3425: Return position `impl Trait` in traits](https://rust-lang.github.io/rfcs/3425-return-position-impl-trait-in-traits.html) merged

<!--These will render pretty when pasted into github-->
Non-exhaustive list of PRs that are particularly relevant to the implementation:

- rust-lang#101224
- rust-lang#103491
- rust-lang#104592
- rust-lang#108141
- rust-lang#108319
- rust-lang#108672
- rust-lang#112988
- rust-lang#113182 (later made redundant by rust-lang#114489)
- rust-lang#113215
- rust-lang#114489
- rust-lang#115467
- rust-lang#115582

Doc co-authored by `@nikomatsakis,` `@tmandry,` `@traviscross.` Thanks also to `@spastorino,` `@cjgillot` (for changes to opaque captures!), `@oli-obk` for many reviews, and many other contributors and issue-filers. Apologies if I left your name off 😺
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Oct 17, 2023
Stabilize `async fn` and return-position `impl Trait` in trait

# Stabilization report

This report proposes the stabilization of `#![feature(return_position_impl_trait_in_trait)]` ([RPITIT][RFC 3425]) and `#![feature(async_fn_in_trait)]` ([AFIT][RFC 3185]). These are both long awaited features that increase the expressiveness of the Rust language and trait system.

Closes #91611

[RFC 3185]: https://rust-lang.github.io/rfcs/3185-static-async-fn-in-trait.html
[RFC 3425]: https://rust-lang.github.io/rfcs/3425-return-position-impl-trait-in-traits.html

## Updates from thread

The thread has covered two major concerns:

* [Given that we don't have RTN, what should we stabilize?](rust-lang/rust#115822 (comment)) -- proposed resolution is [adding a lint](rust-lang/rust#115822 (comment)) and [careful messaging](rust-lang/rust#115822 (comment))
* [Interaction between outlives bounds and capture semantics](rust-lang/rust#115822 (comment)) -- This is fixable in a forwards-compatible way via #116040, and also eventually via ATPIT.

## Stabilization Summary

This stabilization allows the following examples to work.

### Example of return-position `impl Trait` in trait definition

```rust
trait Bar {
    fn bar(self) -> impl Send;
}
```

This declares a trait method that returns *some* type that implements `Send`.  It's similar to writing the following using an associated type, except that the associated type is anonymous.

```rust
trait Bar {
    type _0: Send;
    fn bar(self) -> Self::_0;
}
```

### Example of return-position `impl Trait` in trait implementation

```rust
impl Bar for () {
    fn bar(self) -> impl Send {}
}
```

This defines a method implementation that returns an opaque type, just like [RPIT][RFC 1522] does, except that all in-scope lifetimes are captured in the opaque type (as is already true for `async fn` and as is expected to be true for RPIT in Rust Edition 2024), as described below.

[RFC 1522]: https://rust-lang.github.io/rfcs/1522-conservative-impl-trait.html

### Example of `async fn` in trait

```rust
trait Bar {
    async fn bar(self);
}

impl Bar for () {
    async fn bar(self) {}
}
```

This declares a trait method that returns *some* [`Future`](https://doc.rust-lang.org/core/future/trait.Future.html) and a corresponding method implementation.  This is equivalent to writing the following using RPITIT.

```rust
use core::future::Future;

trait Bar {
    fn bar(self) -> impl Future<Output = ()>;
}

impl Bar for () {
    fn bar(self) -> impl Future<Output = ()> { async {} }
}
```

The desirability of this desugaring being available is part of why RPITIT and AFIT are being proposed for stabilization at the same time.

## Motivation

Long ago, Rust added [RPIT][RFC 1522] and [`async`/`await`][RFC 2394].  These are major features that are widely used in the ecosystem.  However, until now, these feature could not be used in *traits* and trait implementations.  This left traits as a kind of second-class citizen of the language.  This stabilization fixes that.

[RFC 2394]: https://rust-lang.github.io/rfcs/2394-async_await.html

### `async fn` in trait

Async/await allows users to write asynchronous code much easier than they could before. However, it doesn't play nice with other core language features that make Rust the great language it is, like traits. Support for `async fn` in traits has been long anticipated and was not added before due to limitations in the compiler that have now been lifted.

`async fn` in traits will unblock a lot of work in the ecosystem and the standard library. It is not currently possible to write a trait that is implemented using `async fn`. The workarounds that exist are undesirable because they require allocation and dynamic dispatch, and any trait that uses them will become obsolete once native `async fn` in trait is stabilized.

We also have ample evidence that there is demand for this feature from the [`async-trait` crate][async-trait], which emulates the feature using dynamic dispatch. The async-trait crate is currently the #5 async crate on crates.io ranked by recent downloads, receiving over 78M all-time downloads. According to a [recent analysis][async-trait-analysis], 4% of all crates use the `#[async_trait]` macro it provides, representing 7% of all function and method signatures in trait definitions on crates.io. We think this is a *lower bound* on demand for the feature, because users are unlikely to use `#[async_trait]` on public traits on crates.io for the reasons already given.

[async-trait]: https://crates.io/crates/async-trait
[async-trait-analysis]: https://rust-lang.zulipchat.com/#narrow/stream/315482-t-compiler.2Fetc.2Fopaque-types/topic/RPIT.20capture.20rules.20.28capturing.20everything.29/near/389496292

### Return-position `impl Trait` in trait

`async fn` always desugars to a function that returns `impl Future`.

```rust!
async fn foo() -> i32 { 100 }

// Equivalent to:
fn foo() -> impl Future<Output = i32> { async { 100 } }
```

All `async fn`s today can be rewritten this way. This is useful because it allows adding behavior that runs at the time of the function call, before the first `.await` on the returned future.

In the spirit of supporting the same set of features on `async fn` in traits that we do outside of traits, it makes sense to stabilize this as well. As described by the [RPITIT RFC][rpitit-rfc], this includes the ability to mix and match the equivalent forms in traits and their corresponding impls:

```rust!
trait Foo {
    async fn foo(self) -> i32;
}

// Can be implemented as:
impl Foo for MyType {
    fn foo(self) -> impl Future<Output = i32> {
        async { 100 }
    }
}
```

Return-position `impl Trait` in trait is useful for cases beyond async, just as regular RPIT is. As a simple example, the RFC showed an alternative way of writing the `IntoIterator` trait with one fewer associated type.

```rust!
trait NewIntoIterator {
    type Item;
    fn new_into_iter(self) -> impl Iterator<Item = Self::Item>;
}

impl<T> NewIntoIterator for Vec<T> {
    type Item = T;
    fn new_into_iter(self) -> impl Iterator<Item = T> {
        self.into_iter()
    }
}
```

[rpitit-rfc]: https://rust-lang.github.io/rfcs/3425-return-position-impl-trait-in-traits.html

## Major design decisions

This section describes the major design decisions that were reached after the RFC was accepted:

- EDIT: Lint against async fn in trait definitions

    - Until the [send bound problem](https://smallcultfollowing.com/babysteps/blog/2023/02/01/async-trait-send-bounds-part-1-intro/) is resolved, the use of `async fn` in trait definitions could lead to a bad experience for people using work-stealing executors (by far the most popular choice). However, there are significant use cases for which the current support is all that is needed (single-threaded executors, such as those used in embedded use cases, as well as thread-per-core setups). We are prioritizing serving users well over protecting people from misuse, and therefore, we opt to stabilize the full range of functionality; however, to help steer people correctly, we are will issue a warning on the use of `async fn` in trait definitions that advises users about the limitations. (See [this summary comment](rust-lang/rust#115822 (comment)) for the details of the concern, and [this comment](rust-lang/rust#115822 (comment)) for more details about the reasoning that led to this conclusion.)

- Capture rules:

    - The RFC's initial capture rules for lifetimes in impls/traits were found to be imprecisely precise and to introduce various inconsistencies. After much discussion, the decision was reached to make `-> impl Trait` in traits/impls capture *all* in-scope parameters, including both lifetimes and types. This is a departure from the behavior of RPITs in other contexts; an RFC is currently being authored to change the behavior of RPITs in other contexts in a future edition.

    - Major discussion links:

        - [Lang team design meeting from 2023-07-26](https://hackmd.io/sFaSIMJOQcuwCdnUvCxtuQ?view)

- Refinement:

    - The [refinement RFC] initially proposed that impl signatures that are more specific than their trait are not allowed unless the `#[refine]` attribute was included, but left it as an open question how to implement this. The stabilized proposal is that it is not a hard error to omit `#[refine]`, but there is a lint which fires if the impl's return type is more precise than the trait. This greatly simplified the desugaring and implementation while still achieving the original goal of ensuring that users do not accidentally commit to a more specific return type than they intended.

    - Major discussion links:

        - [Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/.60.23.5Brefine.5D.60.20as.20a.20lint)

[refinement RFC]: https://rust-lang.github.io/rfcs/3245-refined-impls.html

## What is stabilized

### Async functions in traits and trait implementations

* `async fn` are now supported in traits and trait implementations.
* Associated functions in traits that are `async` may have default bodies.

### Return-position impl trait in traits and trait implementations

* Return-position `impl Trait`s are now supported in traits and trait implementations.
    * Return-position `impl Trait` in implementations are treated like regular return-position `impl Trait`s, and therefore behave according to the same inference rules for hidden type inference and well-formedness.
* Associated functions in traits that name return-position `impl Trait`s may have default bodies.
* Implementations may provide either concrete types or `impl Trait` for each corresponding `impl Trait` in the trait method signature.

For a detailed exploration of the technical implementation of return-position `impl Trait` in traits, see [the dev guide](https://rustc-dev-guide.rust-lang.org/return-position-impl-trait-in-trait.html).

### Mixing `async fn` in trait and return-position `impl Trait` in trait

A trait function declaration that is `async fn ..() -> T` may be satisfied by an implementation function that returns `impl Future<Output = T>`, or vice versa.

```rust
trait Async {
    async fn hello();
}

impl Async for () {
    fn hello() -> impl Future<Output = ()> {
        async {}
    }
}

trait RPIT {
    fn hello() -> impl Future<Output = String>;
}

impl RPIT for () {
    async fn hello() -> String {
        "hello".to_string()
    }
}
```

### Return-position `impl Trait` in traits and trait implementations capture all in-scope lifetimes

Described above in "major design decisions".

### Return-position `impl Trait` in traits are "always revealing"

When a trait uses `-> impl Trait` in return position, it logically desugars to an associated type that represents the return (the actual implementation in the compiler is different, as described below). The value of this associated type is determined by the actual return type written in the impl; if the impl also uses `-> impl Trait` as the return type, then the value of the associated type is an opaque type scoped to the impl method (similar to what you would get when calling an inherent function returning `-> impl Trait`). As with any associated type, the value of this special associated type can be revealed by the compiler if the compiler can figure out what impl is being used.

For example, given this trait:

```rust
trait AsDebug {
    fn as_debug(&self) -> impl Debug;
}
```

A function working with the trait generically is only able to see that the return value is `Debug`:

```rust
fn foo<T: AsDebug>(t: &T) {
    let u = t.as_debug();
    println!("{}", u); // ERROR: `u` is not known to implement `Display`
}
```

But if a function calls `as_debug` on a known type (say, `u32`), it may be able to resolve the return type more specifically, if that implementation specifies a concrete type as well:

```rust
impl AsDebug for u32 {
    fn as_debug(&self) -> u32 {
        *self
    }
}

fn foo(t: &u32) {
    let u: u32 = t.as_debug(); // OK!
    println!("{}",  t.as_debug()); // ALSO OK (since `u32: Display`).
}
```

The return type used in the impl therefore represents a **semver binding** promise from the impl author that the return type of `<u32 as AsDebug>::as_debug` will not change. This could come as a surprise to users, who might expect that they are free to change the return type to any other type that implements `Debug`. To address this, we include a [`refining_impl_trait` lint](rust-lang/rust#115582) that warns if the impl uses a specific type -- the `impl AsDebug for u32` above, for example, would toggle the lint.

The lint message explains what is going on and encourages users to `allow` the lint to indicate that they meant to refine the return type:

```rust
impl AsDebug for u32 {
    #[allow(refining_impl_trait)]
    fn as_debug(&self) -> u32 {
        *self
    }
}
```

[RFC #3245](rust-lang/rfcs#3245) proposed a new attribute, `#[refine]`, that could also be used to "opt-in" to refinements like this (and which would then silence the lint). That RFC is not currently implemented -- the `#[refine]` attribute is also expected to reveal other details from the signature and has not yet been fully implemented.

### Return-position `impl Trait` and `async fn` in traits are opted-out of object safety checks when the parent function has `Self: Sized`

```rust
trait IsObjectSafe {
    fn rpit() -> impl Sized where Self: Sized;
    async fn afit() where Self: Sized;
}
```

Traits that mention return-position `impl Trait` or `async fn` in trait when the associated function includes a `Self: Sized` bound will remain object safe. That is because the associated function that defines them will be opted-out of the vtable of the trait, and the associated types will be unnameable from any trait object.

This can alternatively be seen as a consequence of rust-lang/rust#112319 (comment) and the desugaring of return-position `impl Trait` in traits to associated types which inherit the where-clauses of the associated function that defines them.

## What isn't stabilized (aka, potential future work)

### Dynamic dispatch

As stabilized, traits containing RPITIT and AFIT are **not dyn compatible**. This means that you cannot create `dyn Trait` objects from them and can only use static dispatch. The reason for this limitation is that dynamic dispatch support for RPITIT and AFIT is more complex than static dispatch, as described on the [async fundamentals page](https://rust-lang.github.io/async-fundamentals-initiative/evaluation/challenges/dyn_traits.html). The primary challenge to using `dyn Trait` in today's Rust is that **`dyn Trait` today must list the values of all associated types**. This means you would have to write `dyn for<'s> Trait<Foo<'s> = XXX>` where `XXX` is the future type defined by the impl, such as `F_A`. This is not only verbose (or impossible), it also uniquely ties the `dyn Trait` to a particular impl, defeating the whole point of `dyn Trait`.

The precise design for handling dynamic dispatch is not yet determined. Top candidates include:

- [callee site selection][], in which we permit unsized return values so that the return type for an `-> impl Foo` method be can be `dyn Foo`, but then users must specify the type of wide pointer at the call-site in some fashion.

- [`dyn*`][], where we create a built-in encapsulation of a "wide pointer" and map the associated type corresponding to an RPITIT to the corresponding `dyn*` type (`dyn*` itself is not exposed to users as a type in this proposal, though that could be a future extension).

[callee site selection]: https://smallcultfollowing.com/babysteps/blog/2022/09/21/dyn-async-traits-part-9-callee-site-selection/

[`dyn*`]: https://smallcultfollowing.com/babysteps/blog/2022/03/29/dyn-can-we-make-dyn-sized/

### Where-clause bounds on return-position `impl Trait` in traits or async futures (RTN/ART)

One limitation of async fn in traits and RPITIT as stabilized is that there is no way for users to write code that adds additional bounds beyond those listed in the `-> impl Trait`. The most common example is wanting to write a generic function that requires that the future returned from an `async fn` be `Send`:

```rust
trait Greet {
    async fn greet(&self);
}

fn greet_in_parallel<G: Greet>(g: &G) {
    runtime::spawn(async move {
        g.greet().await; //~ ERROR: future returned by `greet` may not be `Send`
    })
}
```

Currently, since the associated types added for the return type are anonymous, there is no where-clause that could be added to make this code compile.

There have been various proposals for how to address this problem (e.g., [return type notation][rtn] or having an annotation to give a name to the associated type), but we leave the selection of one of those mechanisms to future work.

[rtn]: https://smallcultfollowing.com/babysteps/blog/2023/02/13/return-type-notation-send-bounds-part-2/

In the meantime, there are workarounds that one can use to address this problem, listed below.

#### Require all futures to be `Send`

For many users, the trait may only ever be used with `Send` futures, in which case one can write an explicit `impl Future + Send`:

```rust
trait Greet {
    fn greet(&self) -> impl Future<Output = ()> + Send;
}
```

The nice thing about this is that it is still compatible with using `async fn` in the trait impl. In the async working group case studies, we found that this could work for the [builder provider API](https://rust-lang.github.io/async-fundamentals-initiative/evaluation/case-studies/builder-provider-api.html). This is also the default approach used by the `#[async_trait]` crate which, as we have noted, has seen widespread adoption.

#### Avoid generics

This problem only applies when the `Self` type is generic. If the `Self` type is known, then the precise return type from an `async fn` is revealed, and the `Send` bound can be inferred thanks to auto-trait leakage. Even in cases where generics may appear to be required, it is sometimes possible to rewrite the code to avoid them. The [socket handler refactor](https://rust-lang.github.io/async-fundamentals-initiative/evaluation/case-studies/socket-handler.html) case study provides one such example.

### Unify capture behavior for `-> impl Trait` in inherent methods and traits

As stabilized, the capture behavior for `-> impl Trait` in a trait (whether as part of an async fn or a RPITIT) captures all types and lifetimes, whereas the existing behavior for inherent methods only captures types and lifetimes that are explicitly referenced. Capturing all lifetimes in traits was necessary to avoid various surprising inconsistencies; the expressed intent of the lang team is to extend that behavior so that we also capture all lifetimes in inherent methods, which would create more consistency and also address a common source of user confusion, but that will have to happen over the 2024 edition. The RFC is in progress. Should we opt not to accept that RFC, we can bring the capture behavior for `-> impl Trait` into alignment in other ways as part of the 2024 edition.

### `impl_trait_projections`

Orthgonal to `async_fn_in_trait` and `return_position_impl_trait_in_trait`, since it can be triggered on stable code. This will be stabilized separately in [#115659](rust-lang/rust#115659).

<details>
If we try to write this code without `impl_trait_projections`, we will get an error:

```rust
#![feature(async_fn_in_trait)]

trait Foo {
    type Error;
    async fn foo(&mut self) -> Result<(), Self::Error>;
}

impl<T: Foo> Foo for &mut T {
    type Error = T::Error;
    async fn foo(&mut self) -> Result<(), Self::Error> {
        T::foo(self).await
    }
}
```

The error relates to the use of `Self` in a trait impl when the self type has a lifetime. It can be worked around by rewriting the impl not to use `Self`:

```rust
#![feature(async_fn_in_trait)]

trait Foo {
    type Error;
    async fn foo(&mut self) -> Result<(), Self::Error>;
}

impl<T: Foo> Foo for &mut T {
    type Error = T::Error;
    async fn foo(&mut self) -> Result<(), <&mut T as Foo>::Error> {
        T::foo(self).await
    }
}
```
</details>

## Tests

Tests are generally organized between return-position `impl Trait` and `async fn` in trait, when the distinction matters.
* RPITIT: https://github.com/rust-lang/rust/tree/master/tests/ui/impl-trait/in-trait
* AFIT: https://github.com/rust-lang/rust/tree/master/tests/ui/async-await/in-trait

## Remaining bugs and open issues

* #112047: Indirection introduced by `async fn` and return-position `impl Trait` in traits may hide cycles in opaque types, causing overflow errors that can only be discovered by monomorphization.
* #111105 - `async fn` in trait is susceptible to issues with checking auto traits on futures' generators, like regular `async`. This is a manifestation of #110338.
    * This was deemed not blocking because fixing it is forwards-compatible, and regular `async` is subject to the same issues.
* #104689: `async fn` and return-position `impl Trait` in trait requires the late-bound lifetimes in a trait and impl function signature to be equal.
    * This can be relaxed in the future with a smarter lexical region resolution algorithm.
* #102527: Nesting return-position `impl Trait` in trait deeply may result in slow compile times.
    * This has only been reported once, and can be fixed in the future.
* #108362: Inference between return types and generics of a function may have difficulties when there's an `.await`.
    * This isn't related to AFIT (rust-lang/rust#108362 (comment)) -- using traits does mean that there's possibly easier ways to hit it.
* #112626: Because `async fn` and return-position `impl Trait` in traits lower to associated types, users may encounter strange behaviors when implementing circularly dependent traits.
    * This is not specific to RPITIT, and is a limitation of associated types: rust-lang/rust#112626 (comment)
* **(Nightly)** #108309: `async fn` and return-position `impl Trait` in trait do not support specialization. This was deemed not blocking, since it can be fixed in the future (e.g. #108321) and specialization is a nightly feature.

#### (Nightly) Return type notation bugs

RTN is not being stabilized here, but there are some interesting outstanding bugs. None of them are blockers for AFIT/RPITIT, but I'm noting them for completeness.

<details>

* #109924 is a bug that occurs when a higher-ranked trait bound has both inference variables and associated types. This is pre-existing -- RTN just gives you a more convenient way of producing them. This should be fixed by the new trait solver.
* #109924 is a manifestation of a more general issue with `async` and auto-trait bounds: #110338. RTN does not cause this issue, just allows us to put `Send` bounds on the anonymous futures that we have in traits.
* #112569 is a bug similar to associated type bounds, where nested bounds are not implied correctly.

</details>

## Alternatives

### Do nothing

We could choose not to stabilize these features. Users that can use the `#[async_trait]` macro would continue to do so. Library maintainers would continue to avoid async functions in traits, potentially blocking the stable release of many useful crates.

### Stabilize `impl Trait` in associated type instead

AFIT and RPITIT solve the problem of returning unnameable types from trait methods. It is also possible to solve this by using another unstable feature, `impl Trait` in an associated type. Users would need to define an associated type in both the trait and trait impl:

```rust!
trait Foo {
    type Fut<'a>: Future<Output = i32> where Self: 'a;
    fn foo(&self) -> Self::Fut<'_>;
}

impl Foo for MyType {
    type Fut<'a> where Self: 'a = impl Future<Output = i32>;
    fn foo(&self) -> Self::Fut<'_> {
        async { 42 }
    }
}
```

This also has the advantage of allowing generic code to bound the associated type. However, it is substantially less ergonomic than either `async fn` or `-> impl Future`, and users still expect to be able to use those features in traits. **Even if this feature were stable, we would still want to stabilize AFIT and RPITIT.**

That said, we can have both. `impl Trait` in associated types is desireable because it can be used in existing traits with explicit associated types, among other reasons. We *should* stabilize this feature once it is ready, but that's outside the scope of this proposal.

### Use the old capture semantics for RPITIT

We could choose to make the capture rules for RPITIT consistent with the existing rules for RPIT. However, there was strong consensus in a recent [lang team meeting](https://hackmd.io/sFaSIMJOQcuwCdnUvCxtuQ?view) that we should *change* these rules, and furthermore that new features should adopt the new rules.

This is consistent with the tenet in RFC 3085 of favoring ["Uniform behavior across editions"](https://rust-lang.github.io/rfcs/3085-edition-2021.html#uniform-behavior-across-editions) when possible. It greatly reduces the complexity of the feature by not requiring us to answer, or implement, the design questions that arise out of the interaction between the current capture rules and traits. This reduction in complexity – and eventual technical debt – is exactly in line with the motivation listed in the aforementioned RFC.

### Make refinement a hard error

Refinement (`refining_impl_trait`) is only a concern for library authors, and therefore doesn't really warrant making into a deny-by-default warning or an error.

Additionally, refinement is currently checked via a lint that compares bounds in the `impl Trait`s in the trait and impl syntactically. This is good enough for a warning that can be opted-out, but not if this were a hard error, which would ideally be implemented using fully semantic, implicational logic. This was implemented (#111931), but also is an unnecessary burden on the type system for little pay-off.

## History

- Dec 7, 2021: [RFC #3185: Static async fn in traits](https://rust-lang.github.io/rfcs/3185-static-async-fn-in-trait.html) merged
- Sep 9, 2022: [Initial implementation](rust-lang/rust#101224) of AFIT and RPITIT landed
- Jun 13, 2023: [RFC #3425: Return position `impl Trait` in traits](https://rust-lang.github.io/rfcs/3425-return-position-impl-trait-in-traits.html) merged

<!--These will render pretty when pasted into github-->
Non-exhaustive list of PRs that are particularly relevant to the implementation:

- #101224
- #103491
- #104592
- #108141
- #108319
- #108672
- #112988
- #113182 (later made redundant by #114489)
- #113215
- #114489
- #115467
- #115582

Doc co-authored by `@nikomatsakis,` `@tmandry,` `@traviscross.` Thanks also to `@spastorino,` `@cjgillot` (for changes to opaque captures!), `@oli-obk` for many reviews, and many other contributors and issue-filers. Apologies if I left your name off 😺
lu-zero pushed a commit to domo-iot/packages that referenced this pull request Oct 23, 2023
Version 1.72.0 (2023-08-24)
==========================

Language
--------
- [Replace const eval limit by a lint and add an exponential backoff warning](rust-lang/rust#103877)
- [expand: Change how `#![cfg(FALSE)]` behaves on crate root](rust-lang/rust#110141)
- [Stabilize inline asm for LoongArch64](rust-lang/rust#111235)
- [Uplift `clippy::undropped_manually_drops` lint](rust-lang/rust#111530)
- [Uplift `clippy::invalid_utf8_in_unchecked` lint](rust-lang/rust#111543)
- [Uplift `clippy::cast_ref_to_mut` lint](rust-lang/rust#111567)
- [Uplift `clippy::cmp_nan` lint](rust-lang/rust#111818)
- [resolve: Remove artificial import ambiguity errors](rust-lang/rust#112086)
- [Don't require associated types with Self: Sized bounds in `dyn Trait` objects](rust-lang/rust#112319)

Compiler
--------
- [Remember names of `cfg`-ed out items to mention them in diagnostics](rust-lang/rust#109005)
- [Support for native WASM exceptions](rust-lang/rust#111322)
- [Add support for NetBSD/aarch64-be (big-endian arm64).](rust-lang/rust#111326)
- [Write to stdout if `-` is given as output file](rust-lang/rust#111626)
- [Force all native libraries to be statically linked when linking a static binary](rust-lang/rust#111698)
- [Add Tier 3 support for `loongarch64-unknown-none*`](rust-lang/rust#112310)
- [Prevent `.eh_frame` from being emitted for `-C panic=abort`](rust-lang/rust#112403)
- [Support 128-bit enum variant in debuginfo codegen](rust-lang/rust#112474)
- [compiler: update solaris/illumos to enable tsan support.](rust-lang/rust#112039)

Refer to Rust's [platform support page][platform-support-doc]
for more information on Rust's tiered platform support.

Libraries
---------
- [Document memory orderings of `thread::{park, unpark}`](rust-lang/rust#99587)
- [io: soften ‘at most one write attempt’ requirement in io::Write::write](rust-lang/rust#107200)
- [Specify behavior of HashSet::insert](rust-lang/rust#107619)
- [Relax implicit `T: Sized` bounds on `BufReader<T>`, `BufWriter<T>` and `LineWriter<T>`](rust-lang/rust#111074)
- [Update runtime guarantee for `select_nth_unstable`](rust-lang/rust#111974)
- [Return `Ok` on kill if process has already exited](rust-lang/rust#112594)
- [Implement PartialOrd for `Vec`s over different allocators](rust-lang/rust#112632)
- [Use 128 bits for TypeId hash](rust-lang/rust#109953)
- [Don't drain-on-drop in DrainFilter impls of various collections.](rust-lang/rust#104455)
- [Make `{Arc,Rc,Weak}::ptr_eq` ignore pointer metadata](rust-lang/rust#106450)

Rustdoc
-------
- [Allow whitespace as path separator like double colon](rust-lang/rust#108537)
- [Add search result item types after their name](rust-lang/rust#110688)
- [Search for slices and arrays by type with `[]`](rust-lang/rust#111958)
- [Clean up type unification and "unboxing"](rust-lang/rust#112233)

Stabilized APIs
---------------
- [`impl<T: Send> Sync for mpsc::Sender<T>`](https://doc.rust-lang.org/nightly/std/sync/mpsc/struct.Sender.html#impl-Sync-for-Sender%3CT%3E)
- [`impl TryFrom<&OsStr> for &str`](https://doc.rust-lang.org/nightly/std/primitive.str.html#impl-TryFrom%3C%26'a+OsStr%3E-for-%26'a+str)
- [`String::leak`](https://doc.rust-lang.org/nightly/alloc/string/struct.String.html#method.leak)

These APIs are now stable in const contexts:

- [`CStr::from_bytes_with_nul`](https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)
- [`CStr::to_bytes`](https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)
- [`CStr::to_bytes_with_nul`](https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)
- [`CStr::to_str`](https://doc.rust-lang.org/nightly/std/ffi/struct.CStr.html#method.from_bytes_with_nul)

Cargo
-----
- Enable `-Zdoctest-in-workspace` by default. When running each documentation
  test, the working directory is set to the root directory of the package the
  test belongs to.
  [docs](https://doc.rust-lang.org/nightly/cargo/commands/cargo-test.html#working-directory-of-tests)
  [openwrt#12221](rust-lang/cargo#12221)
  [openwrt#12288](rust-lang/cargo#12288)
- Add support of the "default" keyword to reset previously set `build.jobs`
  parallelism back to the default.
  [openwrt#12222](rust-lang/cargo#12222)

Compatibility Notes
-------------------
- [Alter `Display` for `Ipv6Addr` for IPv4-compatible addresses](rust-lang/rust#112606)
- Cargo changed feature name validation check to a hard error. The warning was
  added in Rust 1.49. These extended characters aren't allowed on crates.io, so
  this should only impact users of other registries, or people who don't publish
  to a registry.
  [openwrt#12291](rust-lang/cargo#12291)

Refreshed patches.

Signed-off-by: Tianling Shen <[email protected]>
@QuineDot
Copy link

Specifying non-dyn-usable associated types is not 100% useless (see issue #125660.) For example...

One area I could see this getting slightly weird is around "bridging" impls like impl Foo for &dyn Foo. In that case you still want to use ! or its equivalent and have methods panic in some cases. But that's a sign that you probably shouldn't be writing such an impl (for these traits) in the first place, and the situation already exists for where Self: Sized methods.

...you could impl Foo { Assoc = A; } for &dyn Foo<Assoc = A>, when there's a sensible way to do so.

I think that ideally long term you would be allowed to not implement items that have where clauses that are known to not hold

There's an accepted RFC going the other direction (allowing where clauses that never hold in more cases).

@lqd lqd mentioned this pull request May 30, 2024
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jul 29, 2024
…, r=oli-obk

Don't elaborate associated types with Sized bounds in `trait_object_ty` in cfi

The elaboration mechanism introduced in rust-lang#123005 didn't filter for associated types with `Self: Sized` bounds, which since rust-lang#112319 has excluded them from the object type.

Fixes rust-lang#127881
cc `@maurer` `@rcvalle`
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Jul 29, 2024
Rollup merge of rust-lang#127882 - compiler-errors:cfi-sized-self-gat, r=oli-obk

Don't elaborate associated types with Sized bounds in `trait_object_ty` in cfi

The elaboration mechanism introduced in rust-lang#123005 didn't filter for associated types with `Self: Sized` bounds, which since rust-lang#112319 has excluded them from the object type.

Fixes rust-lang#127881
cc `@maurer` `@rcvalle`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-associated-items Area: Associated items (types, constants & functions) disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. T-lang Relevant to the language team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.