Actually deprecate collections::Bound

[bstrie]

In f2c7917 , intrinsics::drop_in_place was supposedly deprecated in favor of ptr::drop_in_place:

#[rustc_deprecated(
    reason = "no longer an intrinsic - use `ptr::drop_in_place` directly",
    since = "1.18.0"
)]
pub use crate::ptr::drop_in_place;

However, this function does not show up as deprecated in the library docs (https://doc.rust-lang.org/nightly/std/intrinsics/fn.drop_in_place.html), nor does it trigger the deprecation warning in the following program:

fn main() {
    let x = &mut 42 as *mut i32;
    unsafe { core::intrinsics::drop_in_place(x); }
}

Presumably this is an unforeseen inability of #[rustc_deprecated] to operate on re-exports. Regardless it means that this function was never actually deprecated in practice, and it will need be deprecated for real with an updated since value.

This can be resolved by simply making intrinsics::drop_in_place into an actual function that merely wraps and calls ptr::drop_in_place, then and then applying #[rustc_deprecated] to it. Alternatively one could fix #[rustc_deprecated] to work when applied to re-exports, but that seems far more involved.

---

Edit: I've also discovered another example of this, which is collections::Bound:

#[rustc_deprecated(reason = "moved to `std::ops::Bound`", since = "1.26.0")]
#[doc(hidden)]
pub use crate::ops::Bound;

The problem in this case is a bit more difficult than with drop_in_place and requires a bit more care. To wit, function items aren't nominal types, so redefining intrinsics::drop_in_place as a wrapper over ptr::drop_in_place isn't a breaking change. However, redefining collections::Bound as a newtype over ops::Bound would create a new nominal type, and would be a breaking change. Furthermore, type aliases via type aren't fully at parity with "real" types, so there might be potential for breakage if one were to simply do pub type Bound = ops::Bound; (I can confirm that the #[deprecated] attribute does work on type aliases). However, I think in practice it should(?) be alright to use a type alias here (the only disparity I can think of with type aliases is that they can't be used as constructors for unit structs, but I'd like second opinions).

[bstrie]

Reopening because the new deprecation of collections::Bound (but not intrinsics::drop_in_place) will need to be reverted (#83269). Basically, type aliases can't be used to import enum variants, so we either need to fix that (#83248) or we need to make it possible to deprecate re-exports (#30827) and avoid type aliases altogether.

See also https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/unavoidable.20breakage.20when.20deprecating.20an.20enum.3F .

[RalfJung]

Uh, I don't think this should have been closed again.

@flip1995 somehow, as part of #83480, you pushed a commit that caused this to be re-closed.

[flip1995]

Whoops, commit b62694b got synced back and forth for some reason.

[RalfJung]

Oh I think I see what happened... the original commit did a lot of things, among them fixing clippy. The commit description contained "Fixes #82080". Each commit that affects clippy is synced to clippy (creating a new commit ID since all the non-clippy changes are removed from it), and then that is synced back (with the same commit ID as what it got in clippy). So now we got a fresh commit that still has "Fixes #82080" in its description.

This sounds like a general problem with the subtree approach...