[core] Fix a soundness hole in core::sync::Exclusive

[dead-claudia]

Just like Mutex<T> is only Sync if T is Send, Exclusive<T> should contain the same constraints.

As an example, sd_journal* instances created per https://www.freedesktop.org/software/systemd/man/sd_journal_open.html# cannot be either Send or Sync, and wrapper types likewise can't.

All functions listed here are thread-agnostic and only a single specific thread may operate on a given object during its entire lifetime. It's safe to allocate multiple independent objects and use each from a specific thread in parallel. However, it's not safe to allocate such an object in one thread, and operate or free it from any other, even if locking is used to ensure these threads don't operate on it at the very same time.

The current API would technically allow a wrapper that (correctly) doesn't implement Send or Sync to be erroneously moved to another thread. This fixes that soundness hole.

Edit: Relevant issue: #98407

[rustbot]

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

Please see the contribution instructions for more information.

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[dead-claudia]

@rustbot label +T-libs-api -T-libs

[clubby789]

The purpose of Exclusive is to always implement Sync, so adding bounds goes against the documented behavior. This implementation upholds the contract for Sync:

the safety requirements of Sync state that for Exclusive to be Sync, it must be sound to share across threads, that is, it must be sound for &Exclusive to cross thread boundaries. By design, a &Exclusive has no API whatsoever, making it useless, thus harmless, thus memory safe.

For the given example of sd_journal*, it is also safe to send pointers across threads, as dereferencing them would require additional unsafe.

[ibraheemdev]

The current API would technically allow a wrapper that (correctly) doesn't implement Send or Sync to be erroneously moved to another thread.

It does not, because Exclusive<T: !Send> does not implement Send.

[dead-claudia]

Closed since I can't seem to find a std counterexample to @ibraheemdev's claim.