Remove support for dyn* from the compiler
#143036
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @SparrowLii rustbot has assigned @SparrowLii. Use |
rustbot
added
A-tidy
|
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 cc @jieyouxu Some changes occurred in compiler/rustc_codegen_ssa 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 Some changes occurred in compiler/rustc_sanitizers cc @rcvalle The Miri subtree was changed cc @rust-lang/miri This PR changes a file inside |
This comment has been minimized.
This comment has been minimized.
compiler-errors
force-pushed
the
no-dyn-star
branch
from
443ab20 to
965c86a
Compare
bors
added
S-waiting-on-bors
|
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. |
|
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
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
Jun 27, 2025
…-obk Remove support for `dyn*` from the compiler This PR removes support for `dyn*` (rust-lang#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[^1] -- 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. [^1]: Compared to, e.g., generators whih are an unstable building block we use to implement stable syntax like `async {}`. 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. ```rust #![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: ```rust #![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](rust-lang#102425 (comment)) 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 rust-lang#102425. cc `@eholk` `@rust-lang/lang` `@rust-lang/types` Closes rust-lang#116979. Closes rust-lang#119694. Closes rust-lang#134591. Closes rust-lang#104800.
bors
added a commit
that referenced
this pull request
Jun 27, 2025
Rollup of 6 pull requests Successful merges: - #142270 (Rustdoc js: even more typechecking improvements) - #142420 (Report infer ty errors during hir ty lowering) - #142818 (Port `#[used]` to new attribute parsing infrastructure) - #143020 (codegen_fn_attrs: make comment more precise) - #143036 (Remove support for `dyn*` from the compiler) - #143060 (Only args in main diag are saved and restored without removing the newly added ones) r? `@ghost` `@rustbot` modify labels: rollup
|
I wonder if it's the one which failed in #143081? |
|
This is proving bitrotty. @bors p=1 |
bors
added a commit
that referenced
this pull request
Jun 27, 2025
Rollup of 9 pull requests Successful merges: - #139858 (New const traits syntax) - #140809 (Reduce special casing for the panic runtime) - #142730 (suggest declaring modules when file found but module not defined) - #142806 (Normalize before computing ConstArgHasType goal in new solver) - #143046 (const validation: properly ignore zero-sized UnsafeCell) - #143092 (const checks for lifetime-extended temporaries: avoid 'top-level scope' terminology) - #143096 (tag_for_variant: properly pass TypingEnv) - #143104 (hir_analysis: prohibit `dyn PointeeSized`) - #143106 (gce: don't ICE on non-local const) Failed merges: - #143036 (Remove support for `dyn*` from the compiler) r? `@ghost` `@rustbot` modify labels: rollup
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this pull request
Jun 28, 2025
Rollup of 9 pull requests Successful merges: - rust-lang/rust#139858 (New const traits syntax) - rust-lang/rust#140809 (Reduce special casing for the panic runtime) - rust-lang/rust#142730 (suggest declaring modules when file found but module not defined) - rust-lang/rust#142806 (Normalize before computing ConstArgHasType goal in new solver) - rust-lang/rust#143046 (const validation: properly ignore zero-sized UnsafeCell) - rust-lang/rust#143092 (const checks for lifetime-extended temporaries: avoid 'top-level scope' terminology) - rust-lang/rust#143096 (tag_for_variant: properly pass TypingEnv) - rust-lang/rust#143104 (hir_analysis: prohibit `dyn PointeeSized`) - rust-lang/rust#143106 (gce: don't ICE on non-local const) Failed merges: - rust-lang/rust#143036 (Remove support for `dyn*` from the compiler) r? `@ghost` `@rustbot` modify labels: rollup
compiler-errors
force-pushed
the
no-dyn-star
branch
from
965c86a to
ec3ec91
Compare
compiler-errors
force-pushed
the
no-dyn-star
branch
from
ec3ec91 to
2516c33
Compare
|
@bors r=oli-obk |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-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 71e4c00 (parent) -> 085c247 (this PR) Test differencesShow 126 test diffsStage 1
Stage 2
Additionally, 34 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 085c24790e591948f788fd294ca3f9858313741c --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
This was referenced Jul 2, 2025
Merged
|
Finished benchmarking commit (085c247): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary -1.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -0.2%, secondary 4.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (secondary -0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 463.343s -> 462.05s (-0.28%) |
tautschnig
added a commit
to tautschnig/kani
that referenced
this pull request
Jul 4, 2025
Relevant upstream PRs: - rust-lang/rust#143214 (Remove let_chains unstable feature) - rust-lang/rust#143036 (Remove support for `dyn*` from the compiler) The latter was tracked as an unsupported feature in Kani, whereby we can resolve one of our own issues as well. Resolves: model-checking#4196 Resolves: model-checking#1784
2 tasks
github-merge-queue bot
pushed a commit
to model-checking/kani
that referenced
this pull request
Jul 10, 2025
Relevant upstream PRs: - rust-lang/rust#143214 (Remove let_chains unstable feature) - rust-lang/rust#143036 (Remove support for `dyn*` from the compiler) The latter was tracked as an unsupported feature in Kani, whereby we can resolve one of our own issues as well. Resolves: #4196 Resolves: #1784 By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.
flip1995
pushed a commit
to flip1995/rust-clippy
that referenced
this pull request
Jul 10, 2025
Rollup of 9 pull requests Successful merges: - rust-lang/rust#139858 (New const traits syntax) - rust-lang/rust#140809 (Reduce special casing for the panic runtime) - rust-lang/rust#142730 (suggest declaring modules when file found but module not defined) - rust-lang/rust#142806 (Normalize before computing ConstArgHasType goal in new solver) - rust-lang/rust#143046 (const validation: properly ignore zero-sized UnsafeCell) - rust-lang/rust#143092 (const checks for lifetime-extended temporaries: avoid 'top-level scope' terminology) - rust-lang/rust#143096 (tag_for_variant: properly pass TypingEnv) - rust-lang/rust#143104 (hir_analysis: prohibit `dyn PointeeSized`) - rust-lang/rust#143106 (gce: don't ICE on non-local const) Failed merges: - rust-lang/rust#143036 (Remove support for `dyn*` from the compiler) r? `@ghost` `@rustbot` modify labels: rollup
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Jul 10, 2025
Remove support for `dyn*` from the compiler This PR removes support for `dyn*` (rust-lang#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[^1] -- 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. [^1]: Compared to, e.g., generators whih are an unstable building block we use to implement stable syntax like `async {}`. 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. ```rust #![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: ```rust #![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](rust-lang#102425 (comment)) 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 rust-lang#102425. cc `@eholk` `@rust-lang/lang` `@rust-lang/types` Closes rust-lang#116979. Closes rust-lang#119694. Closes rust-lang#134591. Closes rust-lang#104800.
Merged
fmease
added a commit
to fmease/rust
that referenced
this pull request
Sep 18, 2025
Clean up `ty::Dynamic` 1. As a follow-up to PR rust-lang#143036, remove `DynKind` entirely. 2. Inside HIR ty lowering, consolidate modules `dyn_compatibility` and `lint` into `dyn_trait` * `dyn_compatibility` wasn't about dyn compatibility itself, it's about lowering trait object types * `lint` contained dyn-Trait-specific diagnostics+lints only
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Sep 18, 2025
Clean up `ty::Dynamic` 1. As a follow-up to PR rust-lang#143036, remove `DynKind` entirely. 2. Inside HIR ty lowering, consolidate modules `dyn_compatibility` and `lint` into `dyn_trait` * `dyn_compatibility` wasn't about dyn compatibility itself, it's about lowering trait object types * `lint` contained dyn-Trait-specific diagnostics+lints only
rust-timer
added a commit
that referenced
this pull request
Sep 18, 2025
Rollup merge of #146664 - fmease:clean-up-dyn, r=jdonszelmann Clean up `ty::Dynamic` 1. As a follow-up to PR #143036, remove `DynKind` entirely. 2. Inside HIR ty lowering, consolidate modules `dyn_compatibility` and `lint` into `dyn_trait` * `dyn_compatibility` wasn't about dyn compatibility itself, it's about lowering trait object types * `lint` contained dyn-Trait-specific diagnostics+lints only
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 way1 -- for us to implement AFIDT. Given that AFIDT was the original motivating purpose ofdyn*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 Traittypes 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.And:
...and probably many more problems having to do with the intersection of dyn-compatibility and
Self: Sizedbounds that I was too lazy to look into like:Generally,
dyn*types also end up getting in the way of working with normaldyntypes 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 betweendyn*and dyn-compatibility before we think about reimplementing them in the type system.I'm planning on removing the
DynKindenum and thePointerLikebuilt-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
Compared to, e.g., generators whih are an unstable building block we use to implement stable syntax like
async {}. ↩