Introduce CoerceShared lang item and trait, and basic Reborrow tests #146037
Conversation
|
r? @nnethercote rustbot has assigned @nnethercote. Use |
|
The definition I use of a marker trait is a trait with no items, so this would not be a marker trait. (This concept comes up in regards to coherence; it is sound to allow overlapping impls of marker traits, because they don't have items whose definitions can conflict.) |
Alright; I was kind of just following CoercePointee since the names are similar :D Would this be more appropriate in ops perhaps? Or somewhere else entirely? |
|
This looks fine to me from the compiler side, where very little code is added. Any controversial bits seems to be libs/lang related, where I don't have much insight. I will forward this review on to Tyler who knows more about it. I'm not sure if a library reviewer should also be involved. r? @tmandry |
Part of #145612: This introduces the
CoerceSharedtrait which is theReborrowequivalent of a&mut T->&Tcoercion. The trait has aTargetGAT which makes this (currently) unique in thecore/src/marker.rs; I'm not sure if this can be considered problematic. Maybe this is not the way such things should be done at the marker trait level? Or maybe it is fine.Improtantly, this PR introduces a battery of basic
ReborrowandCoerceSharedtests. These test the very basics of the feature; custom marker types intended to have exclusive semantics (Custom<'a>(PhantomData<&'a mut ()>)), custom exclusive reference wrappers, and standard library exclusive reference wrappers (Pin<&mut T>andOption<&mut T>). None of these of course work since the implementation forReborrowandCoerceSharedis entirely missing, but this is the first step towards making these work.Future PRs will introduce more tests, such as "recursive" reborrowing (ie. reborrowing structs that contain multiple reborrowable fields) and checks around the lifetime semantics of reborrowing ie. that a reborrow produces a new type with the same lifetime as the original.