Reorganise std::unstable::mutex to add an RAII unlocker to the mutex & replace LittleLock

[huonw]

• adds a LockGuard type returned by .lock and .trylock that unlocks the mutex in the destructor
• renames mutex::Mutex to StaticNativeMutex
• adds a NativeMutex type with a destructor
• removes LittleLock
• adds #[must_use] to sync::mutex::Guard to remind people to use it

[flaper87]

Could you add a test for lock_noguard too?

[alexcrichton]

I feel like this should also rename unlock to unlock_noguard to explicitly say that you don't need to call unlock unless you called lock_noguard. I don't think it will be called in the common case.

Currently Mutex isn't quite a drop-in replacement for LittleLock because LittleLock implements Drop but Mutex does not. The changes you made from LittleLock => Mutex are sadly currently leaking their mutex.

To solve this, we could have Mutex and StaticMutex like with sync::mutex, which is a bit sad, but I'm not entirely sure what the answer would be otherwise.

[huonw]

The changes you made from LittleLock => Mutex are sadly currently leaking their mutex.

Whoops. I imagine Mutex doesn't have a destructor on purpose?

[sfackler]

It allows for static mutexes (yay C libraries).

[nikomatsakis]

This is not sound without the revised destructor rules, from what I can see. On phone so cannot look up the relevant issue.

[huonw]

@nikomatsakis I'm not sure I understand... this doesn't add or remove destructors from any types (but does add an entirely new type with a destructor).

[alexcrichton]

This looks great to me, nice work!

r=me with comments fixed

[alexcrichton]

While you're at it, can you make this a NativeMutex?

[nikomatsakis]

@huonw I think I was wrong, I believe it is ok so long as the fields of all types with an unsafe dtor are private, to prevent surprise mutations -- but it all makes me a bit nervous. We need to finish #8861 (and perhaps #6834), since this kind of ad-hoc rule breakery is hard to verify and a bit creepy.