Update __rust_[rd]ealloc to take NonNull<u8> instead of *mut u8

[scottmcm]

Passing null to it is already UB per Miri anyway, and this is ABI-compatible as NonNull is repr(transparent).

Inspired by #152702 (comment) ; Similar to #152605 which changed align: usize to align: ptr::Alignment.

[rustbot]

r? @joboet

rustbot has assigned @joboet.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: libs
• libs expanded to 7 candidates
• Random selection from Mark-Simulacrum, joboet

[scottmcm]

Notably, this lets us avoid the transmute back from NonNull to *mut.

All the alloc code is doing the NonNull conversion in practice anyway, as it's using https://doc.rust-lang.org/std/alloc/struct.Global.html#method.deallocate not the alloc::dealloc function directly.

[joboet]

Makes sense to me. Let's see if this has any effect on performance...
@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 0fd2a86 (0fd2a86d7a2a7268acb5d51b0f12ac84d755c77f, parent: 765fd2d8c77a570e7069d9f30bb6d3d8fe437f9e)

[rust-timer]

Finished benchmarking commit (0fd2a86): comparison URL.

Overall result: ❌ regressions - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.9%	[0.9%, 0.9%]	1
Regressions ❌ (secondary)	0.5%	[0.5%, 0.5%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.9%	[0.9%, 0.9%]	1

Max RSS (memory usage)

Results (primary -0.1%, secondary 2.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.2%	[2.4%, 4.0%]	3
Regressions ❌ (secondary)	2.3%	[2.3%, 2.3%]	1
Improvements ✅ (primary)	-3.4%	[-4.9%, -2.2%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.1%	[-4.9%, 4.0%]	6

Cycles

Results (secondary -6.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-6.3%	[-7.2%, -5.2%]	3
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 477.793s -> 479.944s (0.45%)
Artifact size: 397.19 MiB -> 395.22 MiB (-0.50%)

[scottmcm]

That perf run looks fine to me. The one icount regression looks like just inlining noise from different MIR

With no cycle regressions I think there's nothing problematic.

[joboet]

Yeah, that looks acceptable.
@bors r+

[rust-bors]

📌 Commit 2c6ec51 has been approved by joboet

It is now in the queue for this repository.