Add into_inner and get_mut to Mutex and RwLock

[cristicbz]

The implementation for into_inner was a bit more complex than I had hoped for---is there any simpler, less unsafe way of getting around the fact that one can't move out of a Drop struct?

See #28968 and rust-lang/rfcs#1269 .

[rust-highfive]

r? @aturon

(rust_highfive has picked a reviewer for you, use r? to override)

[cristicbz]

cc @gankro @tomaka @alexcrichton

[Gankra]

Just use ptr::read

[Gankra]

Also note that &T coerces to *T

[cristicbz]

Done. (re: coercion, just doing &self.inner didn't type check for some reason---maybe some interaction with type inference.)

[Gankra]

Other than the ptr::read stuff, this looks great! Really thorough. I'm not really qualified to review this kind of code, though.

[cristicbz]

Thanks @gankro! I changed to ptr::read, I'd forgotten about that one.

[cristicbz]

Local (full) make check just finished and passed.

[cristicbz]

@aturon mentioned in a different bug he is going to be unavailable. r? @alexcrichton

[huonw]

This shouldn't close #28968 if it is using it as a tracking issue.

[alexcrichton]

The libs team talked about this today, and the conclusion is that this is good to go. The changes we'd like to see, however, are:

• Could you add these methods to RwLock as well? They'd basically all be doing the same thing.
• It may be good to get some exhaustive matching here to ensure that all struct fields are moved out of when into_inner is called. For example something like:

let (a, b) = {
    let Mutex { ref a, ref b } = self; // note exhaustive match
    (ptr::read(a), ptr::read(b))
};
mem::forget(self);

• Could you add a comment in the destructor as well indicating that into_inner needs to be updated with any changes as well?

[cristicbz]

@huonw Good point, I edited the description to not close the issue.

@alexcrichton That all makes sense, I'll do all of that when I get back from work, thanks!

[cristicbz]

@alexcrichton I implemented everything you asked for, please take a look.

Thanks!

[alexcrichton]

Ah as one final piece, could these #[inline] annotations be left out? These are pretty hefty functions and the inline shouldn't be needed anyway as a result of the generic parameter on Mutex

[cristicbz]

@alexcrichton Done and squashed. Don't feel strongly, but I had added #[inline] before because (a) they're not actually that big (especially get_mut) and (b) consistency with the other methods on the types. That said I don't expect these methods to be called in a tight loop (event get_mut), so this is probably for the better.

The fact that it has a type param doesn't quite imply #[inline], right? It's still a hint for LLVM---I remember when we inlined all the slice methods (also type param'd) and it made a massive impact on perf.

[alexcrichton]

@bors: r+ 90ccefd

Thanks!

Yeah #[inline] is an extra hint on top of monomorphizing to LLVM but it rarely has a massive impact on perf for generic functions. The real impact it has is when a function is otherwise not translated across crates (e.g. a concrete function like str::len).

[bors]

⌛ Testing commit 90ccefd with merge 6cdf31b...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt