Rollup merge of #68381 - mjp41:master, r=Dylan-DPC

Added minor clarification to specification of GlobalAlloc::realloc.

The specification of `realloc` is slightly unclear:

```
    /// * `layout` must be the same layout that was used
    ///   to allocate that block of memory,
```
https://github.com/rust-lang/rust/blob/master/src/libcore/alloc.rs#L541-L542

In the case of an `alloc` or `alloc_zeroed` this is fairly evidently the `layout` parameter passed into the original call.  In the case of a `realloc`, this I assume is `layout` modified to contain `new_size`.  However, I could not find this case specified in the documentation.  Thus technically in a sequence of calls to `realloc`, it would be valid to provide the second call to `realloc` the same `layout` as the first call to `realloc`, which is almost certainly not going to be handled correctly.

This PR attempts to clarify the specification.

1 files changed, 2 insertions, 1 deletions

diff --git a/src/libcore/alloc.rs b/src/libcore/alloc.rs
index 4354e1c7b5f..09f743fb81e 100644
--- a/src/libcore/alloc.rs
+++ b/src/libcore/alloc.rs
@@ -525,7 +525,8 @@ pub unsafe trait GlobalAlloc {
     /// The memory may or may not have been deallocated,
     /// and should be considered unusable (unless of course it was
     /// transferred back to the caller again via the return value of
-    /// this method).
+    /// this method). The new memory block is allocated with `layout`, but
+    /// with the `size` updated to `new_size`.
     ///
     /// If this method returns null, then ownership of the memory
     /// block has not been transferred to this allocator, and the