update the saftey preconditions of from_raw_parts

they now reflect the fact that
zero-capacity collections do not allocate

fixes #119304

Author: lolbinarycat

library/alloc/src/string.rs

@@ -913,10 +913,9 @@ impl String {
     /// This is highly unsafe, due to the number of invariants that aren't
     /// checked:
     ///
-    /// * The memory at `buf` needs to have been previously allocated by the
-    ///   same allocator the standard library uses, with a required alignment of exactly 1.
+    /// * unless `capacity` is 0, `buf` must have been allocated using the global allocator with an alignment of 1 and a capacity of `capacity`.
+    /// * `buf` must not be null.
     /// * `length` needs to be less than or equal to `capacity`.
-    /// * `capacity` needs to be the correct value.
     /// * The first `length` bytes at `buf` need to be valid UTF-8.
     ///
     /// Violating these may cause problems like corrupting the allocator's

library/alloc/src/vec/mod.rs

@@ -503,8 +503,9 @@ impl<T> Vec<T> {
     /// This is highly unsafe, due to the number of invariants that aren't
     /// checked:
     ///
-    /// * `ptr` must have been allocated using the global allocator, such as via
+    /// * unless `capacity` is 0 or `T` has size 0, `ptr` must have been allocated using the global allocator, such as via
     ///   the [`alloc::alloc`] function.
+    /// * `ptr` must not be null.
     /// * `T` needs to have the same alignment as what `ptr` was allocated with.
     ///   (`T` having a less strict alignment is not sufficient, the alignment really
     ///   needs to be equal to satisfy the [`dealloc`] requirement that memory must be
@@ -514,12 +515,12 @@ impl<T> Vec<T> {
     ///   alignment, [`dealloc`] must be called with the same layout `size`.)
     /// * `length` needs to be less than or equal to `capacity`.
     /// * The first `length` values must be properly initialized values of type `T`.
-    /// * `capacity` needs to be the capacity that the pointer was allocated with.
+    /// * `capacity` needs to be the capacity that the pointer was allocated with, or 0 in the case of a dangling pointer.
     /// * The allocated size in bytes must be no larger than `isize::MAX`.
     ///   See the safety documentation of [`pointer::offset`].
     ///
     /// These requirements are always upheld by any `ptr` that has been allocated
-    /// via `Vec<T>`. Other allocation sources are allowed if the invariants are
+    /// via `Vec<T>`.  Note that a `Vec` of capacity 0 does not allocate.  Other allocation sources are allowed if the invariants are
     /// upheld.
     ///
     /// Violating these may cause problems like corrupting the allocator's
@@ -724,7 +725,7 @@ impl<T, A: Allocator> Vec<T, A> {
     /// This is highly unsafe, due to the number of invariants that aren't
     /// checked:
     ///
-    /// * `ptr` must be [*currently allocated*] via the given allocator `alloc`.
+    /// * unless `capacity` is 0, `ptr` must be [*currently allocated*] via the given allocator `alloc`.
     /// * `T` needs to have the same alignment as what `ptr` was allocated with.
     ///   (`T` having a less strict alignment is not sufficient, the alignment really
     ///   needs to be equal to satisfy the [`dealloc`] requirement that memory must be
@@ -739,7 +740,7 @@ impl<T, A: Allocator> Vec<T, A> {
     ///   See the safety documentation of [`pointer::offset`].
     ///
     /// These requirements are always upheld by any `ptr` that has been allocated
-    /// via `Vec<T, A>`. Other allocation sources are allowed if the invariants are
+    /// via `Vec<T, A>`. Note that a `Vec` of capacity 0 does not allocate. Other allocation sources are allowed if the invariants are
     /// upheld.
     ///
     /// Violating these may cause problems like corrupting the allocator's