Skip to content

Actually deprecate collections::Bound #82080

Open

Description

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    A-lintArea: Lints (warnings about flaws in source code) such as unused_mut.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions