Validity of Box<T>

[RalfJung]

What is the validity invariant of Box<T>? If this was just a library type it would be the same as Unique<T>, which is the same as NonNull<T>. But actually most of the compiler treats Box<T> a lot like a reference, so at least de-facto right now, Box<T> likely has the same validity invariant as &T and &mut T (which is discussed in #76 and #77).

Also see some prior discussion in rust-lang/rust-memory-model#3.

[gnzlbg]

I think that the validity invariant of Box is the same as NonNull<T>.

The safety invariant of Box are different.

[hanna-kruppe]

Boxes get annotated with attributes/metadata like noalias, align, dereferenceable, etc. which makes it immediate UB to e.g. pass an unaligned Box or a dangling Box around. Treating Box as just a non-null raw pointer is not enough to justify that.

[gnzlbg]

Thanks for pointing that out.

Summary from Discord chat with @rkruppe: Currently we generate noalias for Box, and noalias is only allowed on function arguments and return values in LLVM-IR. This means that if we want to generate the same LLVM-IR that we generate today, the validity invariant for Box needs to be pretty much that of &mut T.

We also talked about whether it would be possible to enforce noalias on access to the Box only, (e.g. Deref/DerefMut could cast the NonNull<T> to a &mut T, and dereference that). This would allow relaxing the validity invariant of Box, and make noalias and the other properties part of its safety invariant. But this does not appear to be possible with LLVM today, and might never be. Relaxing the validity invariant does not enable users to do anything new, since they can always start using NonNull, and only upgrade to Box when the validity invariant is satisfied.

[RalfJung]

We really emit dereferencable? That's interesting, considering that the Box might well be deallocated during the functions runtime! For this reason, Stacked Borrows does not add a "protector" for Box (formerly "barrier", that's the mechanism that Stacked Borrows uses to justify the dereferencable attribute by making sure that the reference remains dereferencable during the entire runtime of the function).

[gnzlbg]

We really emit dereferencable?

@RalfJung This (https://rust.godbolt.org/z/E6Sl8a):

fn foo(x: Box<i32>) -> i32 { *x }

produces

define i32 @foo(i32* noalias align 4 dereferenceable(4)) unnamed_addr #0 {
start:
  %1 = load i32, i32* %0, align 4
  %2 = bitcast i32* %0 to i8*
  tail call void @__rust_dealloc(i8* nonnull %2, i64 4, i64 4) #1
  ret i32 %1
}

[nico-abram]

The godbolt link doesn't seem to produce dereferenceable any more

[RalfJung]

Yes, that was changed with rust-lang/rust#66645.

[nico-abram]

Just wanted to mention here that the validity invariants of Box seem to contradict an assumption evmap had for shallow copying Box: jonhoo/left-right#74

It even has a derive for it's ShallowCopy trait which could be used on aggregates with Box fields

[RalfJung]

I think that issue is less about the validity invariant and more about the aliasing requirements.

[nico-abram]

You're completely right, I was a bit confused because noalias and dereferenceable were mentioned earlier in this thread

I was under the impression "language UB" was validity invariants (#77 (comment)). Are aliasing (And I suppose providence) requirements considered separate from validity and safety invariants?