Initial support for auto traits with default bounds

[Bryanskiy]

This PR is part of "MCP: Low level components for async drop"
Tracking issue: #138781
Summary: #120706 (comment)

Intro

Sometimes we want to use type system to express specific behavior and provide safety guarantees. This behavior can be specified by various "marker" traits. For example, we use Send and Sync to keep track of which types are thread safe. As the language develops, there are more problems that could be solved by adding new marker traits:

• to forbid types with an async destructor to be dropped in a synchronous context a trait like SyncDrop could be used Async destructors, async genericity and completion futures.
• to support scoped tasks or in a more general sense to provide a destruction guarantee there is a desire among some users to see a Leak (or Forget) trait.
• Withoutboats in his post reflected on the use of Move trait instead of a Pin.

All the traits proposed above are supposed to be auto traits implemented for most types, and usually implemented automatically by compiler.

For backward compatibility these traits have to be added implicitly to all bound lists in old code (see below). Adding new default bounds involves many difficulties: many standard library interfaces may need to opt out of those default bounds, and therefore be infected with confusing ?Trait syntax, migration to a new edition may contain backward compatibility holes, supporting new traits in the compiler can be quite difficult and so forth. Anyway, it's hard to evaluate the complexity until we try the system on a practice.

In this PR we introduce new optional lang items for traits that are added to all bound lists by default, similarly to existing Sized. The examples of such traits could be Leak, Move, SyncDrop or something else, it doesn't matter much right now (further I will call them DefaultAutoTrait's). We want to land this change into rustc under an option, so it becomes available in bootstrap compiler. Then we'll be able to do standard library experiments with the aforementioned traits without adding hundreds of #[cfg(not(bootstrap))]s. Based on the experiments, we can come up with some scheme for the next edition, in which such bounds are added in a more targeted way, and not just everywhere.

Most of the implementation is basically a refactoring that replaces hardcoded uses of Sized with iterating over a list of traits including both Sized and the new traits when -Zexperimental-default-bounds is enabled (or just Sized as before, if the option is not enabled).

Default bounds for old editions

All existing types, including generic parameters, are considered Leak/Move/SyncDrop and can be forgotten, moved or destroyed in generic contexts without specifying any bounds. New types that cannot be, for example, forgotten and do not implement Leak can be added at some point, and they should not be usable in such generic contexts in existing code.

To both maintain this property and keep backward compatibility with existing code, the new traits should be added as default bounds everywhere in previous editions. Besides the implicit Sized bound contexts that includes supertrait lists and trait lists in trait objects (dyn Trait1 + ... + TraitN). Compiler should also generate implicit DefaultAutoTrait implementations for foreign types (extern { type Foo; }) because they are also currently usable in generic contexts without any bounds.

Supertraits

Adding the new traits as supertraits to all existing traits is potentially necessary, because, for example, using a Self param in a trait's associated item may be a breaking change otherwise:

trait Foo: Sized {
    fn new() -> Option<Self>; // ERROR: `Option` requires `DefaultAutoTrait`, but `Self` is not `DefaultAutoTrait`
}

// desugared `Option`
enum Option<T: DefaultAutoTrait + Sized> {
    Some(T),
    None,
}

However, default supertraits can significantly affect compiler performance. For example, if we know that T: Trait, the compiler would deduce that T: DefaultAutoTrait. It also implies proving F: DefaultAutoTrait for each field F of type T until an explicit impl is be provided.

If the standard library is not modified, then even traits like Copy or Send would get these supertraits.

In this PR for optimization purposes instead of adding default supertraits, bounds are added to the associated items:

// Default bounds are generated in the following way:
trait Trait {
   fn foo(&self) where Self: DefaultAutoTrait {}
}

// instead of this:
trait Trait: DefaultAutoTrait {
   fn foo(&self) {}
}

It is not always possible to do this optimization because of backward compatibility:

pub trait Trait<Rhs = Self> {}
pub trait Trait1 : Trait {} // ERROR: `Rhs` requires `DefaultAutoTrait`, but `Self` is not `DefaultAutoTrait`

or

trait Trait {
   type Type where Self: Sized;
}
trait Trait2<T> : Trait<Type = T> {} // ERROR: `???` requires `DefaultAutoTrait`, but `Self` is not `DefaultAutoTrait`

Therefore, DefaultAutoTrait's are still being added to supertraits if the Self params or type bindings were found in the trait header.

Trait objects

Trait objects requires explicit + Trait bound to implement corresponding trait which is not backward compatible:

fn use_trait_object(x: Box<dyn Trait>) {
   foo(x) // ERROR: `foo` requires `DefaultAutoTrait`, but `dyn Trait` is not `DefaultAutoTrait`
}

// implicit T: DefaultAutoTrait here
fn foo<T>(_: T) {}

So, for a trait object dyn Trait we should add an implicit bound dyn Trait + DefaultAutoTrait to make it usable, and allow relaxing it with a question mark syntax dyn Trait + ?DefaultAutoTrait when it's not necessary.

Foreign types

If compiler doesn't generate auto trait implementations for a foreign type, then it's a breaking change if the default bounds are added everywhere else:

// implicit T: DefaultAutoTrait here
fn foo<T: ?Sized>(_: &T) {}

extern "C" {
    type ExternTy;
}

fn forward_extern_ty(x: &ExternTy) {
    foo(x); // ERROR: `foo` requires `DefaultAutoTrait`, but `ExternTy` is not `DefaultAutoTrait`
}

We'll have to enable implicit DefaultAutoTrait implementations for foreign types at least for previous editions:

// implicit T: DefaultAutoTrait here
fn foo<T: ?Sized>(_: &T) {}

extern "C" {
    type ExternTy;
}

impl DefaultAutoTrait for ExternTy {} // implicit impl

fn forward_extern_ty(x: &ExternTy) {
    foo(x); // OK
}

Unresolved questions

New default bounds affect all existing Rust code complicating an already complex type system.

• Proving an auto trait predicate requires recursively traversing the type and proving the predicate for it's fields. This leads to a significant performance regression. Measurements for the stage 2 compiler build show up to 3x regression.
  • We hope that fast path optimizations for well known traits could mitigate such regressions at least partially.
• New default bounds trigger some compiler bugs in both old and new trait solver.
• With new default bounds we encounter some trait solver cycle errors that break existing code.
  • We hope that these cases are bugs that can be addressed in the new trait solver.

Also migration to a new edition could be quite ugly and enormous, but that's actually what we want to solve. For other issues there's a chance that they could be solved by a new solver.

[Bryanskiy]

@rustbot author

[petrochenkov]

So, what are the goals here:

• We want to have a possibility to add new auto traits that are added to all bound lists by default on the current edition. The examples of such traits could be Leak, Move, SyncDrop or something else, it doesn't matter much right now. The desired behavior is similar to the current Sized trait. Such behavior is required for introducing !Leak or !SyncDrop types in a backward compatible way. (Both Leak and SyncDrop are likely necessary for properly supporting libraries for scoped async tasks and structured concurrency.)
• It's not clear whether it can be done backward compatibly and without significant perf regressions, but that's exactly what we want to find out. Right now we encounter some cycle errors and exponential blow ups in the trait solver, but there's a chance that they are fixable with the new solver.
• Then we want to land the change into rustc under an option, so it becomes available in bootstrap compiler. Then we'll be able to do standard library experiments with the aforementioned traits without adding hundreds of #[cfg(not(bootstrap))]s.
• Based on the experiments, we can come up with some scheme for the next edition, in which such bounds are added more conservatively.
• Relevant blog posts - https://without.boats/blog/changing-the-rules-of-rust/, https://without.boats/blog/follow-up-to-changing-the-rules-of-rust/ and https://without.boats/blog/generic-trait-methods-and-new-auto-traits/, https://without.boats/blog/the-scoped-task-trilemma/
• Larger compiler team MCP including this feature - MCP: Low level components for async drop compiler-team#727, it gives some more context

[petrochenkov]

The issue right now is that there are regressions, some previously passing code now fails due to cycles in trait solver or something similar, @Bryanskiy has been trying to investigate it, but without success.

@lcnr, this is the work I've been talking about today.
(Maybe it makes sense to ping some other types team members as well?)

[Bryanskiy]

I want to reproduce regressions in CI

@rustbot author

[lcnr]

it would be good to get an MVCE for the new cycles, otherwise debugging this without fully going through the PR is hard

[lcnr]

do these tests have to be no_core?

There's some mini_core or whatever somewhere. It's better to reuse that one rather than manually adding required lang items. Otherwise these tests have to all be separately fixed if it starts to rely on additional core lang itms

[Bryanskiy]

I would prefer to keep these tests isolated. Default auto traits can poison lang item trait implementations like in #120706 (comment).

[lcnr]

There's //@ add-core-stubs which means you still don't depend on all of core but avoid breaking the tests in case we end up with another required lang item.

[lcnr]

I guess you want to avoid DispatchFromDyn in your test... however, if that already doesn't work, is experimenting with this feature at all useful 😅 I feel like you won't learn anything too insightful about it if something this core already does not work

[Bryanskiy]

What do you mean by "it does not work"? A little more context on the issue with lang items:

For !Leak types to be able to call methods, Leak bound should be relaxed for Receiver implementations:

#[lang = "legacy_receiver"]
trait LegacyReceiver {}
impl<T: ?Sized + ?Leak> LegacyReceiver for &T {}
impl<T: ?Sized + ?Leak> LegacyReceiver for &mut T {}
...

For !Leak trait objects to be able to call methods, Leak bound should be relaxed in DispatchFromDyn:

#[lang = "dispatch_from_dyn"]
pub trait DispatchFromDyn<T: ?Leak> {}

(according to receiver_is_dispatchable compiler will try to prove Receiver: DispatchFromDyn<Receiver>).

I have 2 tests to check this behaviour:

• maybe-bounds-in-dyn-traits.rs (for DispatchFromDyn)
• maybe-bounds-in-traits.rs (for Receiver)

I can't reuse mini_core in this case because of lang items redefinition. Adding experimental lang items to mini_core, instead, and relaxing additional bounds seems like a bad idea.

Maybe I'm missing something, but what is wrong here?

[lcnr]

That makes sense, you actually need to modify mini_core to relax some of the new default bounds

okay, this seems fine then. In case we end up with a lot of tests for default auto traits we should get a new mini_core.rs which is modified for them (or add cfg to the existing one), but for now that seems fine 🤔

[lcnr]

some final comments, after that cleanup, r=me

[lcnr]

why here instead of in the method, why is it even required instead of just using hir_bounds: &[hir::GenericBound<'tcx>]?

[lcnr]

can you instead only do the if lang_:item == LangItem::Sized for the final push/insert instead of duplicating the trait_ref creation?

[Bryanskiy]

It may be worth deleting this branch completely and leaving only "insert", since this only affects performance and diagnostics with experimental traits enabled.

[lcnr]

@bors r+

[bors]

📌 Commit 581c5fb has been approved by lcnr

It is now in the queue for this repository.

[bors]

⌛ Testing commit 581c5fb with merge 9e14530...

[bors]

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing 9e14530 to master...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 4fd8c04 (parent) -> 9e14530 (this PR)

Test differences

Show 16 test diffs

Stage 1

• [ui] tests/ui/traits/default_auto_traits/backward-compatible-lazy-bounds-pass.rs: [missing] -> pass (J1)
• [ui] tests/ui/traits/default_auto_traits/default-bounds.rs: [missing] -> pass (J1)
• [ui] tests/ui/traits/default_auto_traits/extern-types.rs#current: [missing] -> pass (J1)
• [ui] tests/ui/traits/default_auto_traits/extern-types.rs#next: [missing] -> pass (J1)
• [ui] tests/ui/traits/default_auto_traits/maybe-bounds-in-dyn-traits.rs: [missing] -> pass (J1)
• [ui] tests/ui/traits/default_auto_traits/maybe-bounds-in-traits.rs: [missing] -> pass (J1)

Stage 2

• [ui] tests/ui/traits/default_auto_traits/backward-compatible-lazy-bounds-pass.rs: [missing] -> pass (J0)
• [ui] tests/ui/traits/default_auto_traits/default-bounds.rs: [missing] -> pass (J0)
• [ui] tests/ui/traits/default_auto_traits/extern-types.rs#current: [missing] -> pass (J0)
• [ui] tests/ui/traits/default_auto_traits/extern-types.rs#next: [missing] -> pass (J0)
• [ui] tests/ui/traits/default_auto_traits/maybe-bounds-in-dyn-traits.rs: [missing] -> pass (J0)
• [ui] tests/ui/traits/default_auto_traits/maybe-bounds-in-traits.rs: [missing] -> pass (J0)

Additionally, 4 doctest diffs were found. These are ignored, as they are noisy.

Job group index

• J0: aarch64-apple, aarch64-gnu, arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, i686-gnu-1, i686-gnu-nopt-1, i686-msvc-1, test-various, x86_64-apple-2, x86_64-gnu, x86_64-gnu-llvm-18-1, x86_64-gnu-llvm-18-2, x86_64-gnu-llvm-19-1, x86_64-gnu-llvm-19-2, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1
• J1: x86_64-gnu-llvm-18-3, x86_64-gnu-llvm-19-3

Job duration changes

1. aarch64-gnu-debug: 4478.8s -> 6708.5s (49.8%)
2. dist-x86_64-linux: 5080.8s -> 5454.3s (7.3%)
3. dist-various-1: 4364.8s -> 4628.2s (6.0%)
4. dist-aarch64-apple: 4498.9s -> 4756.0s (5.7%)
5. dist-loongarch64-linux: 5979.2s -> 6319.0s (5.7%)
6. dist-x86_64-msvc-alt: 7343.4s -> 7700.2s (4.9%)
7. x86_64-gnu-llvm-18-1: 5374.6s -> 5621.1s (4.6%)
8. i686-mingw-2: 6489.6s -> 6741.3s (3.9%)
9. armhf-gnu: 4418.2s -> 4574.3s (3.5%)
10. dist-x86_64-netbsd: 4917.9s -> 5084.5s (3.4%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (9e14530): comparison URL.

Overall result: ❌ regressions - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

• If the regression was expected or you think it can be justified,
  please write a comment with sufficient written justification, and add
  @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
• If you think that you know of a way to resolve the regression, try to create
  a new PR with a fix for the regression.
• If you do not understand the regression or you think that it is just noise,
  you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
  were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.8%	[0.2%, 1.3%]	7
Regressions ❌ (secondary)	0.4%	[0.2%, 1.1%]	21
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.8%	[0.2%, 1.3%]	7

Max RSS (memory usage)

Results (secondary -0.9%)

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)	5.4%	[5.4%, 5.4%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.0%	[-3.7%, -2.1%]	3
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: 776.101s -> 773.774s (-0.30%)
Artifact size: 365.72 MiB -> 365.73 MiB (0.00%)

[petrochenkov]

Does this include some extra work on a "good path", when no additional auto traits are defined? Perhaps it can be avoided?
I didn't expect a perf regression from this.

[Bryanskiy]

Perhaps it can be avoided?

Yeah, we can skip computing requires_default_supertraits if experimental-default-bounds option is not enabled.