std: Tidy up some `unsafe impl`s for `sync`

This commit removes many unnecessary `unsafe impl` blocks as well as pushing the
needed implementations to the lowest level possible. I noticed that the bounds
for `RwLock` are a little off when reviewing #22574 and wanted to ensure that we
had our story straight on these implementations.

1 files changed, 10 insertions, 7 deletions

diff --git a/src/libstd/sys/windows/mutex.rs b/src/libstd/sys/windows/mutex.rs
index 75495efc7cb..0847f3b52bf 100644
--- a/src/libstd/sys/windows/mutex.rs
+++ b/src/libstd/sys/windows/mutex.rs
@@ -8,7 +8,8 @@
 // option. This file may not be copied, modified, or distributed
 // except according to those terms.
 
-use marker::Sync;
+use prelude::v1::*;
+
 use cell::UnsafeCell;
 use sys::sync as ffi;
 
@@ -18,6 +19,7 @@ pub const MUTEX_INIT: Mutex = Mutex {
     inner: UnsafeCell { value: ffi::SRWLOCK_INIT }
 };
 
+unsafe impl Send for Mutex {}
 unsafe impl Sync for Mutex {}
 
 #[inline]
@@ -27,14 +29,15 @@ pub unsafe fn raw(m: &Mutex) -> ffi::PSRWLOCK {
 
 // So you might be asking why we're using SRWLock instead of CriticalSection?
 //
-// 1. SRWLock is several times faster than CriticalSection according to benchmarks performed on both
-// Windows 8 and Windows 7.
+// 1. SRWLock is several times faster than CriticalSection according to
+//    benchmarks performed on both Windows 8 and Windows 7.
 //
-// 2. CriticalSection allows recursive locking while SRWLock deadlocks. The Unix implementation
-// deadlocks so consistency is preferred. See #19962 for more details.
+// 2. CriticalSection allows recursive locking while SRWLock deadlocks. The Unix
+//    implementation deadlocks so consistency is preferred. See #19962 for more
+//    details.
 //
-// 3. While CriticalSection is fair and SRWLock is not, the current Rust policy is there there are
-// no guarantees of fairness.
+// 3. While CriticalSection is fair and SRWLock is not, the current Rust policy
+//    is there there are no guarantees of fairness.
 
 impl Mutex {
     #[inline]