Repository: rust
Issue: Tracking Issue for `ReentrantLock`
Labels: T-libs-api,C-tracking-issue

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(reentrant_lock)]`

This is a tracking issue for `ReentrantLock`, a re-entrant lock useful for avoiding a common type of deadlocks.

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
// std::sync

pub struct ReentrantLock<T: ?Sized> {}
pub struct ReentrantLockGuard<'a, T: ?Sized + 'a> {}

impl<T> ReentrantLock<T> {
    pub const fn new(t: T) -> ReentrantLock<T>;
    pub fn into_inner(self) -> T;
}

impl<T: ?Sized> ReentrantLock<T> {
    pub fn lock(&self) -> ReentrantLockGuard<'_, T>;
    pub fn get_mut(&mut self) -> &mut T;
}

impl<T: Send + ?Sized> Send for ReentrantLock<T> {}
impl<T: Send + ?Sized> Sync for ReentrantLock<T> {}

impl<T: ?Sized> !Send for ReentrantLockGuard<'_, T> {}
impl<T: ?Sized + Sync> Sync for ReentrantLockGuard<'_, T> {}

impl<T: UnwindSafe + ?Sized> UnwindSafe for ReentrantLock<T> {}
impl<T: RefUnwindSafe + ?Sized> RefUnwindSafe for ReentrantLock<T> {}

impl<T: Default> Default for ReentrantLock<T> {}
impl<T> From<T> for ReentrantLock<T> {}

impl<T: ?Sized> Deref for ReentrantLockGuard<'_, T> {
    type Target = T;
}

impl<T: Debug + ?Sized> Debug for ReentrantLock<T> {}
impl<T: Debug + ?Sized> Debug for ReentrantLockGuard<'_, T> {}
impl<T: Display + ?Sized> Display for ReentrantLockGuard<'_, T> {}
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [x] ACP: rust-lang/libs-team#193
- [x] Implementation:
  - #110543
  - https://github.com/rust-lang/rust/pull/125527
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

#### Poisoning

I would argue that `ReentrantLock` should **not** implement lock poisoning. Since it only provides shared access, breaking the invariants of the inner type is something that the lock has no control over, as it requires interior mutability. It would make sense to require that `T: RefUnwindSafe`, but I think that is too inconvenient for now. If `RefUnwindSafe` were a lint trait, it should definitely be used.

#### Fallible locking

Is there a need for fallible locking, even if it cannot fail because of reentrancy? How would this look like, considering that `TryLockResult` also has a poisoning case, which would never be used here?

#### Naming

New synchronization primitives like `OnceLock` have used the `Lock` suffix. IMHO the name `ReentrantLock` rhymes well with the other types and is more consistent, but `ReentrantMutex` better highlights the similarity to `Mutex`.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html