Remove bevy_ptr::dangling_with_align() and inline it

[BD103]

Objective

• bevy_ptr::dangling_with_align() is only used once, in bevy_ecs's BlobArray::with_capacity(), and it isn't generally useful outside of the engine's internals. We can remove the function and inline its implementation into its call site.
• Additionally, bevy_ptr::dangling_with_align() has a TODO comment that was leftover from Remove int2ptr cast in bevy_ptr::dangling_with_align and remove -Zmiri-permissive-provenance in CI #15311 (comment), where it was suggested that dangling_with_align() should use without_provenance().
  • with_addr(), mentioned in the TODO comment, could also be used, but it's a more roundabout solution. The reason it was mentioned was because the original author thought it would be stabilized before without_provenance().

Solution

• Remove dangling_with_align().
• Replace its usage with NonNull::without_provenance() (since it is now stable and doesn't require unsafe or pointer math)

Testing

• I ran Miri with strict provenance checking enabled to ensure the behavior is maintained.
  • MIRIFLAGS="-Zmiri-strict-provenance" cargo +nightly miri test

But what is this provenance thingy?

The official docs provide a more in-depth explanation, but basically a pointer is more than just a number referring to a memory address. Pointers have permissions associated with them that track:

• What set of memory addresses are allowed to be accessed
• When the pointer is allowed to access those addresses
• If the pointer is allowed to mutate the memory, or just read it

These permissions are pointer provenance. They aren't stored at runtime, the Rust compiler doesn't know them at compile time! Miri is the only tool that I know of that tracks provenance, which it uses to ensure pointers adheres to their spatial, temporal, and mutability permissions. That's why I mentioned Miri in the Testing section. :)

[alice-i-cecile]

@SkiFire13, want to take a look at this? This was your suggestion I believe.

[github-actions]

Your PR increases Bevy Minimum Supported Rust Version. Please update the rust-version field in the root Cargo.toml file.

[BD103]

NonNull::without_provenance() was stabilized in 1.89.0, but our MSRV was 1.88.0, so I bumped it!

[hymm]

why do we care that the alignment is a power of 2? i.e. why don't we just use NonNull::without_provenance directly?

I only see it being used in bevy here.

bevy/crates/bevy_ecs/src/storage/blob_array.rs

Line 45 in 2a24658

let data = bevy_ptr::dangling_with_align(align);

[SkiFire13]

I'm not sure if it makes sense to bump the MSRV just for this small change.

[BD103]

I personally don't see the harm: without_provenance() is much simpler than what we had before, and it gives Miri extra insight into what we're doing with the pointer. Bevy's MSRV policy has made it clear that we'll take advantage of newly-stabilized features if they're useful to us, so I feel it's fair game.

[BD103]

why do we care that the alignment is a power of 2? i.e. why don't we just use NonNull::without_provenance directly?

I don't know enough myself to speak on this matter, but it appears to be a requirement by Rust. Looking at Layout::align(), it guarantees the result to be a power of two. (And internally it looks like it only powers of two in memory layouts using the Alignment struct / enum.)

I only see it being used in bevy here.

Given how dangling_with_align() is only being used there, we should definitely inline it. I don't think anyone else will miss it if it's gone, and I'll add a migration guide if they do.

[kfc35]

The lint fixes might belong in a different pull request, since it is a little distracting from the purpose listed in the PR title and description. Plus, if you need to revert for whatever reason if the version upgrade or the without_provenance stuff ends up being problematic, the lint changes won’t be tied to the reversion