Make ZeroablePrimitive trait unsafe.

[reitermarkus]

Tracking issue: #120257

r? @dtolnay

[Nilstrieb]

Not dtolnay, but this is obviously correct
@bors r+ rollup

[bors]

📌 Commit f6d2607 has been approved by Nilstrieb

It is now in the queue for this repository.

[dtolnay]

I think this was correct before this PR. The boundary for unsafety to have any meaning in Rust in a public API is the module level. core::num exposes a sound API without this trait being an unsafe trait. Unsafe traits are for when implementing a trait from outside the module can cause unsoundness.

core::any is similar. Implementing Any with a bogus type_id method would cause unsoundness, but it is impossible to do so from outside the module, so there is no need for Any to be an unsafe trait.

[reitermarkus]

I think this was correct before this PR.

Even if it was correct already, I think this makes it more obvious why the trait needs to exist in the first place.

This feels a bit different to Any, which has a blanket implementation for any T, while ZeroablePrimitive needs to be carefully implemented for only very specific types.

[Nilstrieb]

I don't think it's necessarily wrong to not make it unsafe, but I think making it unsafe is clearer

[dtolnay]

The fact that the standard library needs to be careful with impls for this trait is an internal implementation detail of the standard library, which doesn't have bearing on consumers of the standard library. It's a shame that rustdoc would end up emphasizing this implementation detail in public-facing docs. Ideally there would be a way for a trait to be unsafe internally for the purpose of requiring unsafe impl, but without unsafe ending up in the public-facing docs. Analogously to how there needs to be a way for a type to be repr(transparent) internally, but without repr(transparent) ending up in public-facing documentation: #90435. (In both cases, rustdoc with --document-private-items might show it.)

Would it be just as good if Sealed is unsafe and ZeroablePrimitive is safe?

[reitermarkus]

It's a shame that rustdoc would end up emphasizing this implementation detail in public-facing docs.

Would it be just as good if Sealed is unsafe and ZeroablePrimitive is safe?

The way I see it is: If it was stable and not sealed, it would need to be unsafe. Sealing isn't the unsafe part, it's only for forwards compatibility.

I can understand the argument for “it is safe if it is sealed”, but it doesn't feel quite as intuitive to me.

[dtolnay]

Got it. What do you think of whether Sealed needs to be unsafe in addition to ZeroablePrimitive being unsafe? As currently implemented, adding impl<T> Sealed for T {} in libcore would make the API of core::num unsound (for nightly), even without adding any other ZeroablePrimitive impl.

[reitermarkus]

adding impl<T> Sealed for T {} in libcore would make the API of core::num unsound

How would it be unsound? The safety requirement currently states types implementing it must be primitives that are valid when zero. So technically any implementation outside core would be unsound, that makes the API unusable, but not unsound.

Of course if that requirement is relaxed at some point to allow non-primitives, the trait most likely wouldn't be sealed anymore. And at that point it would probably also be renamed to Zeroable.

[dtolnay]

It's not unsound — you are right. Good call. This is the kind of case I had been thinking of:

#![feature(generic_nonzero, nonzero_internals)]

use std::num::{NonZero, ZeroablePrimitive};

#[derive(Copy, Clone)]
#[repr(transparent)]
struct Thing([u8; 3]);

unsafe impl ZeroablePrimitive for Thing {}

fn main() {
    let _ = NonZero::new(Thing([1, 1, 1]));
}

where the existence of a genuinely unnameable Sealed trait (unnameable even for nightly) is loadbearing for upholding #120257 (comment). With this safe-code-only change in libcore:

diff --git a/library/core/src/num/nonzero.rs b/library/core/src/num/nonzero.rs
@@ -20,4 +20,11 @@ mod private {
     #[const_trait]
     pub trait Sealed {}
+
+    #[unstable(
+        feature = "nonzero_internals",
+        reason = "implementation detail which may disappear or be replaced at any time",
+        issue = "none"
+    )]
+    impl<T> const Sealed for T {}
 }

@@ -39,10 +46,3 @@ pub unsafe trait ZeroablePrimitive: Sized + Copy + private::Sealed {}
 macro_rules! impl_zeroable_primitive {
     ($primitive:ty) => {
-        #[unstable(
-            feature = "nonzero_internals",
-            reason = "implementation detail which may disappear or be replaced at any time",
-            issue = "none"
-        )]
-        impl const private::Sealed for $primitive {}
-
         #[unstable(

it would make cargo check succeed but cargo build produce this ICE:

thread 'rustc' panicked at /git/rust/compiler/rustc_abi/src/layout.rs:432:14:
nonscalar layout for layout_scalar_valid_range type: Layout {
...
query stack during panic:
#0 [layout_of] computing layout of `core::num::nonzero::NonZero<Thing>`
#1 [layout_of] computing layout of `core::option::Option<core::num::nonzero::NonZero<Thing>>`
#2 [mir_drops_elaborated_and_const_checked] elaborating drops for `main`
#3 [analysis] running analysis passes on this crate
end of query stack

But a safe standard library code change turning a compiler error into an ICE is not a soundness issue, and I am sure there must be lots of other standard library safe code changes that would do similar. A prerequisite for the standard library being unsound is that user code containing only correct unsafe code would need to compile successfully into a runnable program, instead of check-able program that causes ICE in build — and in any case the unsafe impl in that example is already incorrect, as you've called out.

And I then noticed that the same code even without feature and without any libcore change also triggers the ICE, so the Sealed impls ultimately aren't even relevant to preventing it.

// cargo +nightly-2024-03-17 build

use std::num::{NonZero, ZeroablePrimitive};

#[derive(Copy, Clone)]
#[repr(transparent)]
struct Thing([u8; 3]);

unsafe impl ZeroablePrimitive for Thing {}

fn main() {
    let _ = NonZero::new(Thing([1, 1, 1]));
}

Thanks for the responses!