arbitrary_self_type: insert implied Receiver bound on Deref #138952
+327
−339
Conversation
This file contains 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
rustbot
added
S-waiting-on-review
|
HIR ty lowering was modified cc @fmease |
|
@rustbot labels +F-arbitrary_self_types |
dingxiangfei2009
changed the title
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
@bors try |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 26, 2025
…mpl, r=<try> arbitrary_self_type: insert implied Receiver bound on Deref r? `@nikomatsakis` This is an experimental setup which allows us to assess the impact from inserting an implied supertrait bound `Deref: Receiver`. The observations are as follows. - Thanks to the trait solver, not too many hacks are needed to implement the idea behind [this comment](rust-lang#135881 (comment)), where inductive cycles are admissible. - We want to allow users to continue use the `dyn Deref` type as `Deref` has been `dyn`-compatible. Following the current `dyn`-compatibility rule, it would have been impossible to use `dyn Deref<Target = ..>` because one would need to write `dyn Deref<..> + Receiver<..>` while neither `Deref` nor `Receiver` is an `auto` trait. This is the main change that this PR proposes: we fill in the missing projection bound that `Receiver` demands from a `dyn Deref` and this will remain the only exception. - Finally, the type (pretty-)printing is adjusted so as to not present the frivolous `Receiver::Target = ..` bound. It will always be the same term as `Deref::Target`. I am proposing a crater experiment to see the extent of impact on the existing ecosystem and explore corner cases that I have missed.
compiler-errors
requested changes
Mar 26, 2025
| #[must_use] | ||
| #[stable(feature = "rust1", since = "1.0.0")] | ||
| #[rustc_diagnostic_item = "deref_method"] | ||
| fn deref(&self) -> &<Self as Deref>::Target; |
There was a problem hiding this comment.
Why did you need to change this? Isn't the point of the hack in hir lowering to avoid breakage around T::Target shorthand projections?
| @@ -6,8 +6,8 @@ use rustc_hir::def::{DefKind, Res}; | |||
| use rustc_lint_defs::builtin::UNUSED_ASSOCIATED_TYPE_BOUNDS; | |||
| use rustc_middle::ty::elaborate::ClauseWithSupertraitSpan; | |||
| use rustc_middle::ty::{ | |||
| self, BottomUpFolder, DynKind, ExistentialPredicateStableCmpExt as _, Ty, TyCtxt, TypeFoldable, | |||
| TypeVisitableExt, Upcast, | |||
| self, BottomUpFolder, DynKind, ExistentialPredicateStableCmpExt as _, Interner as _, Ty, | |||
There was a problem hiding this comment.
Why are you importing Interner? There should be no reason to use that trait.
| @@ -112,9 +112,29 @@ impl<'tcx> dyn HirTyLowerer<'tcx> + '_ { | |||
| // let _: &dyn Alias<Assoc = u32> = /* ... */; | |||
| // ``` | |||
| let mut projection_bounds = FxIndexMap::default(); | |||
| let mut auto_fill_bounds: SmallVec<[_; 4]> = smallvec![]; | |||
| let mut push_auto_fill_receiver_bound = |pred: ty::Binder<'tcx, _>| { | |||
There was a problem hiding this comment.
This is a bit overkill. Just take the projection and replace its def id with the one for Receiver::Target.
At that point, this doesn't need to be a callback, just an additional call to insert into the projection bounds map that you can duplicate twice.
| pred.skip_binder().def_id(), | ||
| rustc_hir::LangItem::DerefTarget, | ||
| ) { | ||
| // We need to fill in a `Receiver<Target = ?>` bound because |
There was a problem hiding this comment.
This comment is missing the more important part that a supertrait like Deref: Receiver<Target = Self::Target> does not automatically elaborate into a projection bound for Reciever's Target type.
| .filter(|item| !tcx.generics_require_sized_self(item.def_id)) | ||
| .count() | ||
| }) | ||
| let expected_count = obj.principal_def_id().map_or(0, |principal_def_id| { |
|
☀️ Try build successful - checks-actions |
|
@craterbot check |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-crater
|
🎉 Experiment
|
craterbot
added
S-waiting-on-review
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.
r? @nikomatsakis
This is an experimental setup which allows us to assess the impact from inserting an implied supertrait bound
Deref: Receiver.The observations are as follows.
dyn Dereftype asDerefhas beendyn-compatible. Following the currentdyn-compatibility rule, it would have been impossible to usedyn Deref<Target = ..>because one would need to writedyn Deref<..> + Receiver<..>while neitherDerefnorReceiveris anautotrait. This is the main change that this PR proposes: we fill in the missing projection bound thatReceiverdemands from adyn Derefand this will remain the only exception.Receiver::Target = ..bound. It will always be the same term asDeref::Target.I am proposing a crater experiment to see the extent of impact on the existing ecosystem and explore corner cases that I have missed.