-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Allow codegen to unsize dyn*
to dyn
#106532
Conversation
r? @nagisa (rustbot has picked a reviewer for you, use r? to override) |
r? rust-lang/compiler |
@bors r+ |
@bors r=jackh726 |
📌 Commit d4c4c4354adfe563e7ee00c907c2f029655f2ecf has been approved by It is now in the queue for this repository. |
) => { | ||
assert_eq!(src_dyn_kind, target_dyn_kind); | ||
|
||
) if src_dyn_kind == target_dyn_kind => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note to self: same change needs to be made to cg_clif
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And also in Miri.
@bors r- wait, this needs to be a build-pass test |
d4c4c43
to
170e942
Compare
@bors r=jackh726 |
…=jackh726 Allow codegen to unsize `dyn*` to `dyn` `dyn* Trait` is just another type that implements `Trait`, so we should be able to unsize `&dyn* Trait` into `&dyn Trait` perfectly fine, same for `Box` and other unsizeable types. Fixes rust-lang#106488
170e942
to
70a8d8d
Compare
@bors r=jackh726 |
…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#106167 (Fix invalid syntax and incomplete suggestion in impl Trait parameter type suggestions for E0311) - rust-lang#106309 (Prefer non-`[type error]` candidates during selection) - rust-lang#106532 (Allow codegen to unsize `dyn*` to `dyn`) - rust-lang#106596 (Hide more of long types in E0271) - rust-lang#106638 (std tests: use __OsLocalKeyInner from realstd) - rust-lang#106676 (Test that we cannot use trait impl methods arguments as defining uses) - rust-lang#106702 (Conserve cause of `ImplDerivedObligation` in E0599) - rust-lang#106732 (rustc_llvm: replace llvm::makeArrayRef with ArrayRef constructors.) - rust-lang#106733 (Revert "warn newer available version of the x tool") - rust-lang#106748 (Clean up `OnUnimplementedFormatString::verify`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
cg_clif counterpart to rust-lang/rust#106532
…li-obk Miri: basic dyn* support As usual I am very unsure about the dynamic dispatch stuff, but it passes even the `Pin<&mut dyn* Trait>` test so that is something. TBH I think it was a mistake to make `dyn Trait` and `dyn* Trait` part of the same `TyKind` variant. Almost everywhere in Miri this lead to the wrong default behavior, resulting in strange ICEs instead of nice "unimplemented" messages. The two types describe pretty different runtime data layout after all. Strangely I did not need to do the equivalent of [this diff](rust-lang#106532 (comment)) in Miri. Maybe that is because the unsizing logic matches on `ty::Dynamic(.., ty::Dyn)` already? In `unsized_info` I don't think the `target_dyn_kind` can be `DynStar`, since then it wouldn't be unsized! r? `@oli-obk` Cc `@eholk` (dyn-star) rust-lang#102425
Miri: basic dyn* support As usual I am very unsure about the dynamic dispatch stuff, but it passes even the `Pin<&mut dyn* Trait>` test so that is something. TBH I think it was a mistake to make `dyn Trait` and `dyn* Trait` part of the same `TyKind` variant. Almost everywhere in Miri this lead to the wrong default behavior, resulting in strange ICEs instead of nice "unimplemented" messages. The two types describe pretty different runtime data layout after all. Strangely I did not need to do the equivalent of [this diff](rust-lang/rust#106532 (comment)) in Miri. Maybe that is because the unsizing logic matches on `ty::Dynamic(.., ty::Dyn)` already? In `unsized_info` I don't think the `target_dyn_kind` can be `DynStar`, since then it wouldn't be unsized! r? `@oli-obk` Cc `@eholk` (dyn-star) rust-lang/rust#102425
Miri: basic dyn* support As usual I am very unsure about the dynamic dispatch stuff, but it passes even the `Pin<&mut dyn* Trait>` test so that is something. TBH I think it was a mistake to make `dyn Trait` and `dyn* Trait` part of the same `TyKind` variant. Almost everywhere in Miri this lead to the wrong default behavior, resulting in strange ICEs instead of nice "unimplemented" messages. The two types describe pretty different runtime data layout after all. Strangely I did not need to do the equivalent of [this diff](rust-lang/rust#106532 (comment)) in Miri. Maybe that is because the unsizing logic matches on `ty::Dynamic(.., ty::Dyn)` already? In `unsized_info` I don't think the `target_dyn_kind` can be `DynStar`, since then it wouldn't be unsized! r? `@oli-obk` Cc `@eholk` (dyn-star) rust-lang/rust#102425
Miri: basic dyn* support As usual I am very unsure about the dynamic dispatch stuff, but it passes even the `Pin<&mut dyn* Trait>` test so that is something. TBH I think it was a mistake to make `dyn Trait` and `dyn* Trait` part of the same `TyKind` variant. Almost everywhere in Miri this lead to the wrong default behavior, resulting in strange ICEs instead of nice "unimplemented" messages. The two types describe pretty different runtime data layout after all. Strangely I did not need to do the equivalent of [this diff](rust-lang/rust#106532 (comment)) in Miri. Maybe that is because the unsizing logic matches on `ty::Dynamic(.., ty::Dyn)` already? In `unsized_info` I don't think the `target_dyn_kind` can be `DynStar`, since then it wouldn't be unsized! r? `@oli-obk` Cc `@eholk` (dyn-star) rust-lang/rust#102425
dyn* Trait
is just another type that implementsTrait
, so we should be able to unsize&dyn* Trait
into&dyn Trait
perfectly fine, same forBox
and other unsizeable types.Fixes #106488