RawVecInner: add missing unsafe to unsafe fns

[btj]

Some (module-private) functions in library/alloc/src/raw_vec/mod.rs are unsafe (i.e. may cause UB when called from safe code) but are not marked unsafe. Specifically:

• RawVecInner::grow_exact causes UB if called with len and additional arguments such that len + additional is less than the current capacity. Indeed, in that case it calls Allocator::grow with a new_layout that is smaller than old_layout, which violates a safety precondition.
• The RawVecInner methods for resizing the buffer cause UB if called with an elem_layout different from the one used to initially allocate the buffer, because in that case Allocator::grow or Allocator::shrink are called with an old_layout that does not fit the allocated block, which violates a safety precondition.
• RawVecInner::current_memory might cause UB if called with an elem_layout different from the one used to initially allocate the buffer, because the unchecked_mul might overflow.
• Furthermore, these methods cause UB if called with an elem_layout where the size is not a multiple of the alignment. This is because Layout::repeat is used (in layout_array) to compute the allocation's layout when allocating, which includes padding to ensure alignment of array elements, but simple multiplication is used (in current_memory) to compute the old allocation's layout when resizing or deallocating, which would cause the layout used to resize or deallocate to not fit the allocated block, which violates a safety precondition.

I discovered these issues while performing formal verification of library/alloc/src/raw_vec/mod.rs per Challenge 19 of the AWS Rust Standard Library Verification Contest.

[rustbot]

r? @thomcc

rustbot has assigned @thomcc.
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

[celinval]

Not an std reviewer, but I wanted to suggest that you add safety comments to the functions that you marked as unsafe.

You could even go one step further and try adding contracts to them, but be aware that it is still highly experimental, and it may not work.

[btj]

@celinval I considered that, but I noticed that most of the safety preconditions of the functions that were already marked unsafe were not documented either, so concerns of adhering to existing practice and avoiding excessive "noise" kept me from adding them so far. Happy to add them if @thomcc thinks it makes sense. Mostly each resizing or deallocation method should get a safety precondition saying elem_layout must be the same one used in earlier calls and must have a size that is a multiple of the alignment.