Use MaybeUninit in liballoc

[RalfJung]

All code by @japaric. This is a re-submission of a part of #53508 that hopefully does not regress performance.

[rust-highfive]

r? @Mark-Simulacrum

(rust_highfive has picked a reviewer for you, use r? to override)

[RalfJung]

@bors try

[bors]

⌛ Trying commit faa733d with merge 1102565...

[bors]

☀️ Test successful - status-travis
State: approved= try=True

[RalfJung]

@rust-timer build 1102565

[rust-timer]

Success: Queued 1102565 with parent b1a137d, comparison URL.

[rust-timer]

Finished benchmarking try commit 1102565

[RalfJung]

Looking good, doesn't it?

r? @cramertj

[Mark-Simulacrum]

Can you confirm that despite introducing MaybeUninit we are still the same size? (i.e., same 32-bit word layout as indicated by the comment on len)?

[cramertj]

MaybeUninit won't introduce any additional alignment requirements that aren't present in the type it wraps, and will only increase the size of the resulting type as a result of inhibiting niche-filling optimizations (and u16 has not niches, so this shouldn't be an issue).

[RalfJung]

What would be a good way to test this? We have a way to "hack" a static_assert!, but the size alone won't do it here because there's a ptr right before this, so on 64bit system it'll be 2 ptr-words in size at least. And we cannot yet do an offset! macro in CTFE. I could add a debug_assert! to test the offset at run-time?

However, I agree with what @cramertj said and this is repr(C), so I am not expecting any surprises. Still, would be nice to be sure.

[cramertj]

r=me with @Mark-Simulacrum 's doc nit fixed.

[RalfJung]

r+'ing as per previous review.

@bors r=cramertj

[bors]

📌 Commit e4434be has been approved by cramertj

[bors]

⌛ Testing commit e4434be with merge 567557f...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: cramertj
Pushing 567557f to master...