Tracking Issue for `mem::conjure_zst` (`feature(mem_conjure_zst)`)

[scottmcm]

Feature gate: #![feature(mem_conjure_zst)]

This is a tracking issue for the mem::conjure_zst::<T>() function.

There are a variety of possible ways one can do this without this function, but it provides two advantages:

1. It makes it clearer to the reader what's happening and keeps the code author from needing to decide between zeroed() or uninitialized() or MaybeUninit::new_uninit().assume_init() in situations like
   

   rust/library/alloc/src/vec/into_iter.rs

   Lines 149 to 150 in ab0c2e1

   	// Make up a value of this ZST.
   	Some(unsafe { mem::zeroed() })

2. It provides a convenient place to talk about why it's not just safe to do this in all cases.

Public API

// core::mem

pub const unsafe fn conjure_zst<T>() -> T;

Steps / History

• ACP: Add an unsafe fn for creating a ZST libs-team#292 (comment)
• Library Implementation:
  • Add mem::conjure_zst for creating ZSTs out of nothing #95385
  • add mem::conjure_zst #146479
• Lint Implementation: todo
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• Should we have a lint suggesting that other ways of creating a ZST, particularly things like *ptr::null::<()>() (see Make deref_nullptr deny by default instead of warn #148122 (comment)), should be changed to call this instead (once it's stablized)?

[clarfonthey]

Posting this here since it doesn't have to be part of the initial PR, but I think there should be a lint for creating uninitialised ZSTs using other methods, since this should be the canonical way to do so.

Another potential thing: if we make it so that calling conjure_zst is a compiler error for non-ZSTs, then what exactly is the unsafe signifying? We can't actually cause any undefined behaviour with it, and although it's currently not possible to do this in safe code, I don't think it's necessarily bad to make it safe, although I do think that it shouldn't be used outside unsafe code. Definitely could break invariants with it.

[scottmcm]

Definitely could break invariants with it.

That's why it has to be unsafe -- see the docs in the PR.

I can write code whose soundness depends on the fact that the only way to get an instance of a particular ZST is by asking me. For example, maybe when you ask for the ZST I initialize some static state. Then even if the ZST is Copy, I can require that you pass me an instance of it and I know that said state is already initialized, without needing to check.

But if you can just conjure that ZST in safe code, that would become unsound.

if we make it so that calling conjure_zst is a compiler error for non-ZSTs

Note that it being an error to even mention for a non-ZST would make it not work in the kinds of places that inspired me to make it. If you look at the PR, the uses are guarded by runtime zero-sizedness checks -- the compiler doesn't know it's a ZST. And it's monomorphized for non-ZSTs, those just happen to be in dead code.

[tgross35]

The comment at rust-lang/libs-team#292 (comment) says that conjure_zst::<NotAZst>() should be an unconditional error. On one hand, this makes sense because it is immediate UB. On the other hand, it's an unusual combination to have a hard error depend on whether a type is written out or comes from a generic: feels a bit more like something that would be a deny-by-default lint.

[clarfonthey]

So, I went through a bit of a journey looking into this, and I'll share what's relevant for this discussion.

First, the assertion intrinsics. Right now, we have the following intrinsics which add unconditional panics to cases of methods being used incorrectly. Specifically:

• intrinsics::assert_zero_valid => mem::zeroed
• intrinsics::assert_mem_uninitialized_valid => mem::uninitialized
• intrinsics::assert_inhabited => mem::MaybeUninit::assume_init

I went through adding this in #147287 thinking that this was the mechanism used for the lint, without actually checking. It turns out these exist just for the unconditional panics, and for that, we can use assert_inhabited and a UB assertion for size_of::<T>() == 0 to avoid bloating the code.

Now, the main lint that seems relevant here is invalid_value, which is warn-by-default instead of deny-by-default. This is defined in compiler/rustc_lint/src/builtin.rs and looks for calls to:

• mem::zeroed
• mem::uninitialized
• mem::transmute (if value is zero, this treats like mem::zeroed)
• mem::MaybeUninit::assume_init

Based upon what the libs team said, it's a bit weird that this lint is warn-by-default, and I would assume that this is solely because deny-by-default was causing issues, but I don't actually see any of that searching for invalid_value in the repo.

Basically, I see one of two paths forward:

1. Propose making invalid_value a deny-by-default lint and run crater to see what this breaks.
2. Add a new lint that specifically covers conjure_zst.

I personally think 1 is the better option, but it's worth pointing out both options here.

[RalfJung]

invalid_value (should have been called invalid_values...) specifically checks for, well, invalid values, i.e. for violations of this requirement. I don't think it should also contain checks for random requirements of particular intrinsics.

It was made warn-by-default when we added it and so far nobody tried to raise the default level. 🤷

[RalfJung]

Also, new lints typically need t-lang approval.

[clarfonthey]

Yeah, definitely worth mentioning that regardless of what is done to the lints, it'll almost certainly need T-lang approval. Although to counter what you said, in this case, it would be an invalid value: specifically, the result of calling conjure_zst for a non-ZST would be an invalid value, since it would be an uninit().assert_init() call, which is always invalid unless the type is zero-sized.

Also worth adding here: the unsafety of this function is mostly with regards to API stability, and the fact that you can construct ZSTs that can potentially break APIs that crates rely on for soundness. We can't track any of that whatsoever and that isn't the subject of these lints; it's specifically about whether you pass a non-ZST type to these functions, and whether that can be determined statically or not.

[RalfJung]

Although to counter what you said, in this case, it would be an invalid value: specifically, the result of calling conjure_zst for a non-ZST would be an invalid value, since it would be an uninit().assert_init() call, which is always invalid unless the type is zero-sized.

That's an implementation detail of conjure_zst. As far as its public API is concerned, it's just a precondition violation of some unsafe library function. I don't think this should be grouped with invalid_values.

In particular, the lint should fire even for non-ZST T for which uninit().assert_init() is actually legal (such as MaybeUninit<i32>).

[clarfonthey]

To be fair, I was under the impression initially that the way these hints worked was by knowing that assert_inhabited and the like would always panic, and then firing an unconditional_panic lint. From this perspective, I think that it would be fair to trigger the lint in these cases.

But I guess you're right: this is just a matter of an API violation, not actual UB in all cases.