Implement more traits for guard types

[marcusbuffett]

Implements Hash, PartialEq, Eq, PartialOrd, and Ord for
Ref, RefMut, MutexGuard, RwLockReadGuard, RwLockWriteGuard.

Fixes #24372

Bit of a rust noob, quick questions:

Preferred style wrt x.deref() or *x? I went with * unless it was going to be something too weird like &**.

hash::Hash or Hash? I see that fmt::Display and fmt::Debug are used for the Display and Debug traits, should I prefer that syntax instead?

I saw all the other implementations use #[inline] and I just followed suit, any rules of thumb here, or is it just "use inline everywhere always?"

I didn't see anything in the issue that said exactly what types needed these traits, so I just went with all the types that got Debug and Display in this commit: 14df549, any more types that need these traits?

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @BurntSushi (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[estebank]

I believe these should be marked as unstable with a tracking issue set, but I'll let anyone else in the team correct me.

[Mark-Simulacrum]

We don't track stability on impls of traits today so these are all insta-stable AFAIK; no need to change anything.

[kennytm]

Unless you expect this PR will stay open for 20 days, the since field should still be 1.22.0.

[marcusbuffett]

Done, thanks!

[BurntSushi]

This all seems fine to me, but I'm kind of surprised we didn't already have these impls. @marcusbuffett Could you maybe elaborate on the use case for wanting each of these impls for these types?

cc @rust-lang/libs Is there a reason why we don't have these impls already or is it just that nobody has added them yet?

[marcusbuffett]

@BurntSushi Beyond pointing to the issue (#24372), I can't really elaborate much – I just searched for E-easy && E-Help Wanted tags and chose one. I don't know enough yet about the types to say why the impls should or shouldn't exist. I'd just be guessing, and your guess is better than mine.

[alexcrichton]

Seems like a find idea to me! I think we just haven't gotten around to this previously

[dtolnay]

Seems okay to me. Thanks!

[alexcrichton]

Ok we got a chance to discuss this during the libs triage meeting today. In discussing this we ended up being increasingly wary of the guideline we set forth to add these trait impls and ended up concluding that we may not wish to add these at this time.

These implementations, as added here, wouldn't enable something like MutexGuard<i32> == i32, but that's arguably something we'd like to work. Adding that, however, precludes MutexGuard<i32> == MutexGuard<i32>. We didn't believe there was a clear way to implement this right now as all current strategies had downsides.

The possibility of specialization in the future may end up providing a solution to this problem, and @aturon also mentioned that the lang team is going to be working during the impl period on "deref coercion ergonomics" to alleviate much of the need for these impls in the first place.

In light of all that I'm going to close this for now and we'll likely be removing the guideline indicating that these traits should be implemented temporarily. Regardless though thanks for the PR @marcusbuffett!