Move CoercePointee to core::ops

[Darksonn]

This was suggested by @tmandry.

diff library/core/src/marker.rs library/core/src/ops/unsize.rs

@@ -10,7 +10,7 @@
 /// By using the macro, the following example will compile:
 /// ```
 /// #![feature(derive_coerce_pointee)]
-/// use std::marker::CoercePointee;
+/// use std::ops::CoercePointee;
 /// use std::ops::Deref;
 ///
 /// #[derive(CoercePointee)]
@@ -57,7 +57,7 @@
 ///
 /// ```
 /// #![feature(arbitrary_self_types, derive_coerce_pointee)]
-/// use std::marker::CoercePointee;
+/// use std::ops::CoercePointee;
 /// use std::ops::Deref;
 ///
 /// #[derive(CoercePointee)]
@@ -111,7 +111,7 @@
 ///   (reference, raw pointer, `NonNull`, `Box`, `Rc`, `Arc`, etc.) or another user-defined type
 ///   also using the `#[derive(CoercePointee)]` macro.
 /// * Zero-sized fields must not mention any generic parameters unless the zero-sized field has
-///   type [`PhantomData`].
+///   type [`PhantomData`](crate::marker::PhantomData).
 ///
 /// ## Multiple type parameters
 ///
@@ -119,7 +119,8 @@
 /// used for dynamic dispatch. For example:
 /// ```
 /// # #![feature(derive_coerce_pointee)]
-/// # use std::marker::{CoercePointee, PhantomData};
+/// # use std::marker::PhantomData;
+/// # use std::ops::CoercePointee;
 /// #[derive(CoercePointee)]
 /// #[repr(transparent)]
 /// struct MySmartPointer<#[pointee] T: ?Sized, U> {
@@ -134,7 +135,7 @@
 /// A custom implementation of the `Rc` type:
 /// ```
 /// #![feature(derive_coerce_pointee)]
-/// use std::marker::CoercePointee;
+/// use std::ops::CoercePointee;
 /// use std::ops::Deref;
 /// use std::ptr::NonNull;
 ///

[rustbot]

Some changes occurred in src/tools/cargo

cc @ehuss

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

[rustbot]

r? @tgross35

rustbot has assigned @tgross35.
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

[Veykril]

This will break rust-analyzer tests as these paths are pulled from our mini core which would also need to be adjusted

[Darksonn]

Fixed.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[Darksonn]

@rustbot ready

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[Darksonn]

I fixed the path used by FileDescriptionRef so I don't understand why CoercePointee broke for FileDescriptionRef. :(

[camsteffen]

I think you'll need #[cfg(bootstrap)] std::marker::CoercePointee and #[cfg(not(bootstrap))] std::ops::CoercePointee so that miri can build stage 1 with an older std and stage 2 with a newer std. Check everything using ./x check --stage 2.

[Darksonn]

I see. I thought we got rid of the bootstrap stuff recently, but I guess not everywhere. Thinking about it a bit more, I'm just going to add a re-export and remove it in the next rustc cycle.

I believe that also avoids the need to patch the Rust for Linux job, since it uses the macro too.

[tmandry]

@rustbot label I-lang-nominated I-libs-api-nominated

This puts CoercePointee (the derive) in the same module as CoerceUnsized (the trait). Both are unstable. In terms of semantics they certainly both enable operations. The current docs of the ops module describe it as defining overloadable operators, which is ambiguous in its meaning, but the module includes traits like Deref and Drop which do not always correspond to explicit syntax.

In my view the common thread between traits in the ops module should be that implementing them enables language-level operations on types, including coercions. This has some precedent in that implementing Deref enables new coercions for your type.

If we don't do this we should adopt another framing that explains where traits like the following should go. There is clearly ambiguity here which is how we ended up with CoercePointee and CoerceUnsized in different modules.

• CoercePointee
• CoerceUnsized
• Receiver
• Reborrow
• CoerceShared

[joshtriplett]

We discussed this in @rust-lang/libs-api, and found this change a little odd: we felt like this didn't fit in the current definition of ops (which is described as being for operators). If we want to change that, that'd be a libs-api change.

I also want to observe that there are more locations than just core::marker and core::ops; for instance, core::ptr::Pointee (still unstable).

[Darksonn]

I think there's an argument to be made that it should be in the same location as CoerceUnsized. Right now, that's ops even though unsizing coercions are not an operator.

[scottmcm]

While the behaviour of the trait is lang-relevant, I think where it lives is purely libs-api, and thus this should be entirely their call. (Obviously anyone interested should comment their opinions, but no need for lang to sign off on the organization.)

[joshtriplett]

@Darksonn I'd agree with that, but that one is unstable too. We should put them both in the same module, but we aren't constrained on which module that could be.

[joshtriplett]

We discussed this in today's @rust-lang/lang meeting, and broadly felt like 1) this was a @rust-lang/libs-api decision and 2) we'd love to see a clear design for where new traits should go.

[Darksonn]

Closing as per #123430 (comment) that decided to keep this in marker.