Auto merge of #41357 - frewsxcv:rollup, r=frewsxcv

Rollup of 3 pull requests

- Successful merges: #41262, #41310, #41344
- Failed merges:

src/doc/unstable-book/src/SUMMARY.md

@@ -38,7 +38,7 @@
 - [collections](collections.md)
 - [collections_range](collections-range.md)
 - [command_envs](command-envs.md)
-- [compiler_barriers](compiler-barriers.md)
+- [compiler_fences](compiler-fences.md)
 - [compiler_builtins](compiler-builtins.md)
 - [compiler_builtins_lib](compiler-builtins-lib.md)
 - [concat_idents](concat-idents.md)

src/doc/unstable-book/src/compiler-barriers.md → src/doc/unstable-book/src/compiler-fences.md

@@ -1,12 +1,12 @@
-# `compiler_barriers`
+# `compiler_fences`
 
 The tracking issue for this feature is: [#41091]
 
 [#41091]: https://github.com/rust-lang/rust/issues/41091
 
 ------------------------
 
-The `compiler_barriers` feature exposes the `compiler_barrier` function
+The `compiler_fences` feature exposes the `compiler_fence` function
 in `std::sync::atomic`. This function is conceptually similar to C++'s
 `atomic_signal_fence`, which can currently only be accessed in nightly
 Rust using the `atomic_singlethreadfence_*` instrinsic functions in
@@ -17,18 +17,18 @@ Rust using the `atomic_singlethreadfence_*` instrinsic functions in
 unsafe { asm!("" ::: "memory" : "volatile") };
 ```
 
-A `compiler_barrier` restricts the kinds of memory re-ordering the
+A `compiler_fence` restricts the kinds of memory re-ordering the
 compiler is allowed to do. Specifically, depending on the given ordering
 semantics, the compiler may be disallowed from moving reads or writes
 from before or after the call to the other side of the call to
-`compiler_barrier`. Note that it does **not** prevent the *hardware*
+`compiler_fence`. Note that it does **not** prevent the *hardware*
 from doing such re-ordering. This is not a problem in a single-threaded,
 execution context, but when other threads may modify memory at the same
 time, stronger synchronization primitives are required.
 
 ## Examples
 
-`compiler_barrier` is generally only useful for preventing a thread from
+`compiler_fence` is generally only useful for preventing a thread from
 racing *with itself*. That is, if a given thread is executing one piece
 of code, and is then interrupted, and starts executing code elsewhere
 (while still in the same thread, and conceptually still on the same
@@ -37,7 +37,7 @@ handler is registered. In more low-level code, such situations can also
 arise when handling interrupts, when implementing green threads with
 pre-emption, etc.
 
-To give a straightforward example of when a `compiler_barrier` is
+To give a straightforward example of when a `compiler_fence` is
 necessary, consider the following example:
 
 ```rust
@@ -67,22 +67,22 @@ remember that the compiler is free to swap the stores to
 after `IS_READY` is updated, then the signal handler will see
 `IS_READY=1`, but `IMPORTANT_VARIABLE=0`.
 
-Using a `compiler_barrier`, we can remedy this situation:
+Using a `compiler_fence`, we can remedy this situation:
 
 ```rust
-#![feature(compiler_barriers)]
+#![feature(compiler_fences)]
 # use std::sync::atomic::{AtomicBool, AtomicUsize};
 # use std::sync::atomic::{ATOMIC_BOOL_INIT, ATOMIC_USIZE_INIT};
 # use std::sync::atomic::Ordering;
-use std::sync::atomic::compiler_barrier;
+use std::sync::atomic::compiler_fence;
 
 static IMPORTANT_VARIABLE: AtomicUsize = ATOMIC_USIZE_INIT;
 static IS_READY: AtomicBool = ATOMIC_BOOL_INIT;
 
 fn main() {
     IMPORTANT_VARIABLE.store(42, Ordering::Relaxed);
     // prevent earlier writes from being moved beyond this point
-    compiler_barrier(Ordering::Release);
+    compiler_fence(Ordering::Release);
     IS_READY.store(true, Ordering::Relaxed);
 }
 

src/etc/natvis/libcollections.natvis

@@ -1,16 +1,16 @@
 <?xml version="1.0" encoding="utf-8"?>
 <AutoVisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
   <Type Name="collections::vec::Vec&lt;*&gt;">
-    <DisplayString>{{ size={len} }}</DisplayString>
-    <Expand>
+    <DisplayString>{{ size={len} }}</DisplayString>
+    <Expand>
       <Item Name="[size]" ExcludeView="simple">len</Item>
       <Item Name="[capacity]" ExcludeView="simple">buf.cap</Item>
       <ArrayItems>
         <Size>len</Size>
         <ValuePointer>buf.ptr.pointer.__0</ValuePointer>
       </ArrayItems>
-    </Expand>
-  </Type>
+    </Expand>
+  </Type>
   <Type Name="collections::vec_deque::VecDeque&lt;*&gt;">
     <DisplayString>{{ size={tail &lt;= head ? head - tail : buf.cap - tail + head} }}</DisplayString>
     <Expand>

src/libcore/sync/atomic.rs

@@ -1591,11 +1591,11 @@ pub fn fence(order: Ordering) {
 }
 
 
-/// A compiler memory barrier.
+/// A compiler memory fence.
 ///
-/// `compiler_barrier` does not emit any machine code, but prevents the compiler from re-ordering
+/// `compiler_fence` does not emit any machine code, but prevents the compiler from re-ordering
 /// memory operations across this point. Which reorderings are disallowed is dictated by the given
-/// [`Ordering`]. Note that `compiler_barrier` does *not* introduce inter-thread memory
+/// [`Ordering`]. Note that `compiler_fence` does *not* introduce inter-thread memory
 /// synchronization; for that, a [`fence`] is needed.
 ///
 /// The re-ordering prevented by the different ordering semantics are:
@@ -1617,15 +1617,15 @@ pub fn fence(order: Ordering) {
 /// [`AcqRel`]: enum.Ordering.html#variant.AcqRel
 /// [`Relaxed`]: enum.Ordering.html#variant.Relaxed
 #[inline]
-#[unstable(feature = "compiler_barriers", issue = "41091")]
-pub fn compiler_barrier(order: Ordering) {
+#[unstable(feature = "compiler_fences", issue = "41091")]
+pub fn compiler_fence(order: Ordering) {
     unsafe {
         match order {
             Acquire => intrinsics::atomic_singlethreadfence_acq(),
             Release => intrinsics::atomic_singlethreadfence_rel(),
             AcqRel => intrinsics::atomic_singlethreadfence_acqrel(),
             SeqCst => intrinsics::atomic_singlethreadfence(),
-            Relaxed => panic!("there is no such thing as a relaxed barrier"),
+            Relaxed => panic!("there is no such thing as a relaxed compiler fence"),
             __Nonexhaustive => panic!("invalid memory ordering"),
         }
     }

src/librustc/diagnostics.rs

@@ -327,6 +327,25 @@ struct ListNode {
 This works because `Box` is a pointer, so its size is well-known.
 "##,
 
+E0080: r##"
+This error indicates that the compiler was unable to sensibly evaluate an
+constant expression that had to be evaluated. Attempting to divide by 0
+or causing integer overflow are two ways to induce this error. For example:
+
+```compile_fail,E0080
+enum Enum {
+    X = (1 << 500),
+    Y = (1 / 0)
+}
+```
+
+Ensure that the expressions given can be evaluated as the desired integer type.
+See the FFI section of the Reference for more information about using a custom
+integer type:
+
+https://doc.rust-lang.org/reference.html#ffi-attributes
+"##,
+
 E0106: r##"
 This error indicates that a lifetime is missing from a type. If it is an error
 inside a function signature, the problem may be with failing to adhere to the