Eagerly elaborate auto-trait supertraits into `dyn Trait`#119825

compiler-errors · 2024-01-10T18:10:53Z

When we have a trait like:

trait Foo: Send {}

Then the dyn Foo type is elaborated to include Send as part of its auto-traits list. That means it is the same type as dyn Foo + Send.

Why?

When a auto trait is implied as part of the supertraits of the trait object's principal, the user should never care about whether they explicitly write + AutoTrait or have it implied from the supertrait bounds. This PR removes this subtle distinction.

IMO, It never makes sense for dyn Foo to be a distinct type from dyn Foo + Send, since both implement Send, just via different code paths in the trait solver.

Alternative approach to #119338.

r? lcnr

rustbot · 2024-01-10T18:13:13Z

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

compiler-errors · 2024-01-10T18:25:43Z

@bors try

Eagerly elaborate auto-trait supertraits into `dyn Trait` When we have a trait like: ``` trait Foo: Send {} ``` Then the `dyn Foo` type is elaborated to include `Send` as part of its auto-traits list. That means it is the *same* type as `dyn Foo + Send`. ## Why? When a auto trait is implied as part of the supertraits of the trait object's principal, the user should *never* care about whether they explicitly write `+ AutoTrait` or have it implied from the supertrait bounds. This PR removes this subtle distinction. IMO, It *never* makes sense for `dyn Foo` to be a distinct type from `dyn Foo + Send`, since both implement `Send`, just via different code paths in the trait solver. --- Alternative approach to rust-lang#119338. r? lcnr

bors · 2024-01-10T18:26:54Z

⌛ Trying commit caeda85 with merge 6802c00...

compiler-errors · 2024-01-10T18:32:19Z

@bors try

bors · 2024-01-10T18:33:28Z

⌛ Trying commit dca631c with merge 925e66e...

Eagerly elaborate auto-trait supertraits into `dyn Trait` When we have a trait like: ``` trait Foo: Send {} ``` Then the `dyn Foo` type is elaborated to include `Send` as part of its auto-traits list. That means it is the *same* type as `dyn Foo + Send`. ## Why? When a auto trait is implied as part of the supertraits of the trait object's principal, the user should *never* care about whether they explicitly write `+ AutoTrait` or have it implied from the supertrait bounds. This PR removes this subtle distinction. IMO, It *never* makes sense for `dyn Foo` to be a distinct type from `dyn Foo + Send`, since both implement `Send`, just via different code paths in the trait solver. --- Alternative approach to rust-lang#119338. r? lcnr

bors · 2024-01-10T20:00:04Z

☀️ Try build successful - checks-actions
Build commit: 925e66e (925e66ec5d7d73da31ddd13e53f21e4674feb4ba)

compiler-errors · 2024-01-10T21:06:29Z

@craterbot check

craterbot · 2024-01-10T21:06:41Z

👌 Experiment pr-119825 created and queued.
🤖 Automatically detected try build 925e66e
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2024-01-12T08:23:59Z

🚧 Experiment pr-119825 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2024-01-14T04:51:51Z

🎉 Experiment pr-119825 is completed!
📊 2354 regressed and 6 fixed (406907 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

lcnr · 2024-01-15T07:22:30Z

alright :/ seems like that's not possible, let go with the coercion 😅

compiler-errors · 2024-01-16T16:51:42Z

yeet

…=lcnr Consider principal trait ref's auto-trait super-traits in dyn upcasting Given traits like: ```rust trait Subtrait: Supertrait + Send {} trait Supertrait {} ``` We should be able to upcast `dyn Subtrait` to `dyn Supertrait + Send`. This is not currently possible, because when upcasting, we look at the list of auto traits in the object type (`dyn Subtrait`, which has no auto traits in its bounds) and compare them to the target's auto traits (`dyn Supertrait + Send`, which has `Send` in its bound). Since the target has auto traits that are not present in the source, the upcasting fails. This is overly restrictive, since `dyn Subtrait` will always implement `Send` via its built-in object impl. I propose to loosen this restriction here. r? types --- ### ~~Aside: Fix this in astconv instead?~~ ### edit: This causes too many failures. See rust-lang#119825 (comment) We may also fix this by by automatically elaborating all auto-trait supertraits during `AstConv::conv_object_ty_poly_trait_ref`. That is, we can make it so that `dyn Subtrait` is elaborated into the same type of `dyn Subtrait + Send`. I'm open to considering this solution instead, but it would break coherence in the following example: ```rust trait Foo: Send {} trait Bar {} impl Bar for dyn Foo {} impl Bar for dyn Foo + Send {} //~^ This would begin to be an overlapping impl. ```

Consider principal trait ref's auto-trait super-traits in dyn upcasting Given traits like: ```rust trait Subtrait: Supertrait + Send {} trait Supertrait {} ``` We should be able to upcast `dyn Subtrait` to `dyn Supertrait + Send`. This is not currently possible, because when upcasting, we look at the list of auto traits in the object type (`dyn Subtrait`, which has no auto traits in its bounds) and compare them to the target's auto traits (`dyn Supertrait + Send`, which has `Send` in its bound). Since the target has auto traits that are not present in the source, the upcasting fails. This is overly restrictive, since `dyn Subtrait` will always implement `Send` via its built-in object impl. I propose to loosen this restriction here. r? types --- ### ~~Aside: Fix this in astconv instead?~~ ### edit: This causes too many failures. See rust-lang/rust#119825 (comment) We may also fix this by by automatically elaborating all auto-trait supertraits during `AstConv::conv_object_ty_poly_trait_ref`. That is, we can make it so that `dyn Subtrait` is elaborated into the same type of `dyn Subtrait + Send`. I'm open to considering this solution instead, but it would break coherence in the following example: ```rust trait Foo: Send {} trait Bar {} impl Bar for dyn Foo {} impl Bar for dyn Foo + Send {} //~^ This would begin to be an overlapping impl. ```

rustbot assigned lcnr Jan 10, 2024

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 Jan 10, 2024

compiler-errors added 2 commits January 10, 2024 18:12

Elaborate auto trait super traits in conv_object_poly_trait_ref

a74b042

Deduplicate implied supertraits for pretty printing

caeda85

rust-cloud-vms bot force-pushed the elaborate-dyn branch from 468280f to caeda85 Compare January 10, 2024 18:13

rustbot added the WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) label Jan 10, 2024

compiler-errors linked an issue Jan 10, 2024 that may be closed by this pull request

Cannot dyn upcast to target w/ auto traits implied by source's principal's supertraits #119335

Closed

Add tests

dca631c

craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 10, 2024

craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Jan 14, 2024

compiler-errors closed this Jan 16, 2024

compiler-errors mentioned this pull request Jan 16, 2024

Consider principal trait ref's auto-trait super-traits in dyn upcasting #119338

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Eagerly elaborate auto-trait supertraits into `dyn Trait`#119825