Rename compiler_barrier to compiler_fence

This addresses concerns raised following the merge of #41092.
Specifically:

> The naming of these seems surprising: the multithreaded functions (and
> both the single and multithreaded intrinsics themselves) are fences,
> but this is a barrier. It's not incorrect, but the latter is both
> inconsistent with the existing functions and slightly confusing with
> another type in std (e.g., `Barrier`).

`compiler_fence` carries the same semantic implication that this is a
compiler-only operation, while being more in line with the fence/barrier
concepts already in use in `std`.

1 files changed, 6 insertions, 6 deletions

diff --git a/src/libcore/sync/atomic.rs b/src/libcore/sync/atomic.rs
index 0c70524ead2..fad58deecd4 100644
--- a/src/libcore/sync/atomic.rs
+++ b/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"),
         }
     }