Follow up commit for the issue 39827

- updates documentation on volatile memory intrinsics, now the case of
   zero-sized types is mentioned explicitly.

Volatile memory operations which doesn't affect memory at all are omitted
in LLVM backend, e.g. if number of elements is zero or type used in
generic specialisation is zero-sized, then LLVM intrinsic or related code
is not generated. This was not explicitly documented before in Rust
documentation and potentially could cause issues.

src/libcore/intrinsics.rs

@@ -1044,20 +1044,23 @@ extern "rust-intrinsic" {
     /// a size of `count` * `size_of::<T>()` and an alignment of
     /// `min_align_of::<T>()`
     ///
-    /// The volatile parameter is set to `true`, so it will not be optimized out.
+    /// The volatile parameter is set to `true`, so it will not be optimized out
+    /// unless size is equal to zero.
     pub fn volatile_copy_nonoverlapping_memory<T>(dst: *mut T, src: *const T,
                                                   count: usize);
     /// Equivalent to the appropriate `llvm.memmove.p0i8.0i8.*` intrinsic, with
     /// a size of `count` * `size_of::<T>()` and an alignment of
     /// `min_align_of::<T>()`
     ///
-    /// The volatile parameter is set to `true`, so it will not be optimized out.
+    /// The volatile parameter is set to `true`, so it will not be optimized out
+    /// unless size is equal to zero..
     pub fn volatile_copy_memory<T>(dst: *mut T, src: *const T, count: usize);
     /// Equivalent to the appropriate `llvm.memset.p0i8.*` intrinsic, with a
     /// size of `count` * `size_of::<T>()` and an alignment of
     /// `min_align_of::<T>()`.
     ///
-    /// The volatile parameter is set to `true`, so it will not be optimized out.
+    /// The volatile parameter is set to `true`, so it will not be optimized out
+    /// unless size is equal to zero.
     pub fn volatile_set_memory<T>(dst: *mut T, val: u8, count: usize);
 
     /// Perform a volatile load from the `src` pointer.

src/libcore/ptr.rs

@@ -384,6 +384,12 @@ pub unsafe fn write_unaligned<T>(dst: *mut T, src: T) {
 /// over time. That being said, the semantics will almost always end up pretty
 /// similar to [C11's definition of volatile][c11].
 ///
+/// Compiler shouldn't change relative order or number of volatile memory
+/// operations, however this implies that memory operation actually takes place.
+/// If a zero-sized type is used in a specialisation of `read_volatile`, value
+/// is known at any time and can not be modified outside of program control.
+/// In this case such operation may be omitted by compiler backend.
+///
 /// [c11]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
 ///
 /// # Safety
@@ -427,6 +433,12 @@ pub unsafe fn read_volatile<T>(src: *const T) -> T {
 /// over time. That being said, the semantics will almost always end up pretty
 /// similar to [C11's definition of volatile][c11].
 ///
+/// Compiler shouldn't change relative order or number of volatile memory
+/// operations, however this implies that memory operation actually takes place.
+/// If a zero-sized type is used in a specialisation of `write_volatile`, value
+/// is known at any time and can not be modified outside of program control.
+/// In this case such operation may be omitted by compiler backend.
+///
 /// [c11]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
 ///
 /// # Safety