Remove support for dyn* from the compiler

[compiler-errors]

This PR removes support for dyn* (#102425), which are a currently un-RFC'd experiment that was opened a few years ago to explore a component that we thought was necessary for AFIDT (async fn in dyn trait).

It doesn't seem like we are going to need dyn* types -- even in an not-exposed-to-the-user way¹ -- for us to implement AFIDT. Given that AFIDT was the original motivating purpose of dyn* types, I don't really see a compelling reason to have to maintain their implementation in the compiler.

We've learned quite a lot from dyn*, but I think at this point its current behavior leads to more questions than answers. For example, dyn* support today remains somewhat fragile; it ICEs in many cases where the current "normal" dyn Trait types rely on their unsizedness for their vtable-based implementation to be sound I wouldn't be surprised if it's unsound in other ways, though I didn't play around with it too much. See the examples below.

#![feature(dyn_star)]

trait Foo {
    fn hello(self);
}

impl Foo for usize {
    fn hello(self) {
        println!("hello, world");
    }
}

fn main() {
    let x: dyn* Foo = 1usize;
    x.hello();
}

And:

#![feature(dyn_star)]

trait Trait {
    type Out where Self: Sized;
}

fn main() {
    let x: <dyn* Trait as Trait>::Out;
}

...and probably many more problems having to do with the intersection of dyn-compatibility and Self: Sized bounds that I was too lazy to look into like:

• GATs
• Methods with invalid signatures
• Associated consts

Generally, dyn* types also end up getting in the way of working with normal dyn types to an extent that IMO outweighs the benefit of experimentation.

I recognize that there are probably other, more creative usages of dyn* that are orthogonal to AFIDT. However, I think any work along those lines should first have to think through some of the more fundamental interactions between dyn* and dyn-compatibility before we think about reimplementing them in the type system.

---

I'm planning on removing the DynKind enum and the PointerLike built-in trait from the compiler after this PR lands.

Closes #102425.

cc @eholk @rust-lang/lang @rust-lang/types

Closes #116979.
Closes #119694.
Closes #134591.
Closes #104800.

Footnotes

1. Compared to, e.g., generators whih are an unstable building block we use to implement stable syntax like async {}. ↩

[rustbot]

r? @SparrowLii

rustbot has assigned @SparrowLii.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

HIR ty lowering was modified

cc @fmease

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

There are changes to the tidy tool.

cc @jieyouxu

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred to constck

cc @fee1-dead

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred in compiler/rustc_sanitizers

cc @rcvalle

The Miri subtree was changed

cc @rust-lang/miri

This PR changes a file inside tests/crashes. If a crash was fixed, please move into the corresponding ui subdir and add 'Fixes #' to the PR description to autoclose the issue upon merge.

[matthiaskrgr]

And thus, after almost 3 years, the Rust Dynasty came to an end.

I guess #134591 and #104800 can also be marked as fixed/closed then?

[oli-obk]

r? @oli-obk

@bors r+

[bors]

📌 Commit 965c86a has been approved by oli-obk

It is now in the queue for this repository.

[eholk]

This seems reasonable. We learned some things from the experiment, but it was also a pretty invasive change so it makes sense not to keep paying the upkeep. If we need it again in the future, we know how to do it.

[traviscross]

Thanks to @compiler-errors for the detailed write-up about this in the PR description. That too will be helpful to any future efforts.

[GuillaumeGomez]

I wonder if it's the one which failed in #143081?