Rename Share to Sync

This leaves the `Share` trait at `std::kinds` via a `#[deprecated]` `pub use`
statement, but the `NoShare` struct is no longer part of `std::kinds::marker`
due to #12660 (the build cannot bootstrap otherwise).

All code referencing the `Share` trait should now reference the `Sync` trait,
and all code referencing the `NoShare` type should now reference the `NoSync`
type. The functionality and meaning of this trait have not changed, only the
naming.

Closes #16281
[breaking-change]

src/doc/complement-design-faq.md

@@ -50,15 +50,15 @@ non-deterministic behavior. Rust provides the tools to make using a GC
 possible and even pleasant, but it should not be a requirement for
 implementing the language.
 
-## Non-`Share` `static mut` is unsafe
+## Non-`Sync` `static mut` is unsafe
 
-Types which are [`Share`][share] are thread-safe when multiple shared
-references to them are used concurrently. Types which are not `Share` are not
+Types which are [`Sync`][sync] are thread-safe when multiple shared
+references to them are used concurrently. Types which are not `Sync` are not
 thread-safe, and thus when used in a global require unsafe code to use.
 
-[share]: http://doc.rust-lang.org/core/kinds/trait.Share.html
+[sync]: http://doc.rust-lang.org/core/kinds/trait.Sync.html
 
-### If mutable static items that implement `Share` are safe, why is taking &mut SHARABLE unsafe?
+### If mutable static items that implement `Sync` are safe, why is taking &mut SHARABLE unsafe?
 
 Having multiple aliasing `&mut T`s is never allowed. Due to the nature of
 globals, the borrow checker cannot possibly ensure that a static obeys the

src/doc/guide-unsafe.md

@@ -699,10 +699,10 @@ Other features provided by lang items include:
 - stack unwinding and general failure; the `eh_personality`, `fail_`
   and `fail_bounds_checks` lang items.
 - the traits in `std::kinds` used to indicate types that satisfy
-  various kinds; lang items `send`, `share` and `copy`.
+  various kinds; lang items `send`, `sync` and `copy`.
 - the marker types and variance indicators found in
   `std::kinds::markers`; lang items `covariant_type`,
-  `contravariant_lifetime`, `no_share_bound`, etc.
+  `contravariant_lifetime`, `no_sync_bound`, etc.
 
 Lang items are loaded lazily by the compiler; e.g. if one never uses
 `Box` then there is no need to define functions for `exchange_malloc`

src/doc/rust.md

@@ -2111,7 +2111,7 @@ A complete list of the built-in language items follows:
   : Has a size known at compile time.
 * `copy`
   : Types that do not move ownership when used by-value.
-* `share`
+* `sync`
   : Able to be safely shared between tasks when aliased.
 * `drop`
   : Have destructors.
@@ -2191,8 +2191,8 @@ These types help drive the compiler's analysis
   : This type does not implement "send", even if eligible
 * `no_copy_bound`
   : This type does not implement "copy", even if eligible
-* `no_share_bound`
-  : This type does not implement "share", even if eligible
+* `no_sync_bound`
+  : This type does not implement "sync", even if eligible
 * `managed_bound`
   : This type implements "managed"
 

src/doc/tutorial.md

@@ -2196,7 +2196,7 @@ and may not be overridden:
 Types are sendable
 unless they contain references.
 
-* `Share` - Types that are *threadsafe*.
+* `Sync` - Types that are *threadsafe*.
 These are types that are safe to be used across several threads with access to
 a `&T` pointer. `Mutex<T>` is an example of a *sharable* type with internal mutable data.
 
@@ -2250,7 +2250,7 @@ We say that the `Printable` trait _provides_ a `print` method with the
 given signature.  This means that we can call `print` on an argument
 of any type that implements the `Printable` trait.
 
-Rust's built-in `Send` and `Share` types are examples of traits that
+Rust's built-in `Send` and `Sync` types are examples of traits that
 don't provide any methods.
 
 Traits may be implemented for specific types with [impls]. An impl for
@@ -2535,7 +2535,7 @@ select the method to call at runtime.
 
 This usage of traits is similar to Java interfaces.
 
-There are some built-in bounds, such as `Send` and `Share`, which are properties
+There are some built-in bounds, such as `Send` and `Sync`, which are properties
 of the components of types. By design, trait objects don't know the exact type
 of their contents and so the compiler cannot reason about those properties.
 
@@ -2548,7 +2548,7 @@ trait Foo {}
 trait Bar<T> {}
 
 fn sendable_foo(f: Box<Foo + Send>) { /* ... */ }
-fn shareable_bar<T: Share>(b: &Bar<T> + Share) { /* ... */ }
+fn sync_bar<T: Sync>(b: &Bar<T> + Sync) { /* ... */ }
 ~~~
 
 When no colon is specified (such as the type `Box<Foo>`), it is inferred that the