Skip to content

Implementation: #[feature(sync_nonpoison)], #[feature(nonpoison_mutex)] #144022

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

connortsui20
Copy link
Contributor

@connortsui20 connortsui20 commented Jul 16, 2025

Continuation of #134663

Tracking Issue: #134645

This PR implements a new sync/nonpoison module, as well as the nonpoison variant of the Mutex lock.

There are 2 main changes here, the first is the new nonpoison::mutex module, and the second is the mutex integration tests.

For the nonpoison::mutex module, I did my best to align it with the current state of the poison::mutex module. This means that several unstable features (mapped_lock_guards, lock_value_accessors, and mutex_data_ptr) are also in the new nonpoison::mutex module, under their respective feature gates. Everything else in that file is under the correct feature gate (#[unstable(feature = "nonpoison_mutex", issue = "134645")]).

Everything in the nonpoison::mutex file is essentially identical in spirit, as we are simply removing the error case from the original poison::mutex.

The second big change is in the integration tests. I created a macro called that allows us to duplicate tests that are "generic" over the different mutex types, in that the poison mutex is always unwrapped.

I think that there is an argument against doing this, as it can make the tests a bit harder to understand (and language server capabilities are weaker within macros), but I think the benefit of code deduplication here is worth it. Note that it is definitely possible to generalize this (with a few tweaks) to testing the other nonpoison locks when they eventually get implemented, but I'll leave that for a later discussion.

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jul 16, 2025
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@connortsui20 connortsui20 force-pushed the sync_nonpoison branch 2 times, most recently from e130930 to 804d305 Compare July 18, 2025 08:58
@connortsui20 connortsui20 marked this pull request as ready for review July 18, 2025 09:23
@rustbot
Copy link
Collaborator

rustbot commented Jul 18, 2025

r? @thomcc

rustbot has assigned @thomcc.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 18, 2025
@tgross35
Copy link
Contributor

r? tgross35

@rustbot rustbot assigned tgross35 and unassigned thomcc Jul 18, 2025
@connortsui20 connortsui20 force-pushed the sync_nonpoison branch 5 times, most recently from 35fc4df to 71395b1 Compare July 22, 2025 12:49
Copy link
Contributor

@tgross35 tgross35 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks pretty good to me, most comments here are related to docs. This will need some history cleanup, there isn't any need to preserve the current state of #134663 in history (I assume this was just done for now to show what changed since then)

@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 23, 2025
@rustbot rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jul 23, 2025
Comment on lines 315 to 225
if mem::needs_drop::<T>() {
drop(old)
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if statement does not do anything. The original implementation uses needs_drop to decide whether to utilize replace, while this implementation will call replace unconditionally, potentially causing some memcpy overhead for trivially drop types.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh that makes sense, will change!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you check if this makes sense?

@connortsui20 connortsui20 requested review from tgross35 and EFanZh July 23, 2025 14:17
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 23, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jul 23, 2025

This PR modifies tests/ui/issues/. If this PR is adding new tests to tests/ui/issues/,
please refrain from doing so, and instead add it to more descriptive subdirectories.


/// A lock could not be acquired at this time because the operation would otherwise block.
#[unstable(feature = "sync_nonpoison", issue = "134645")]
pub struct WouldBlock;
Copy link
Contributor

@EFanZh EFanZh Jul 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be better if we make the WouldBlock constructor private? So that if we add new fields to it later, it would not cause breaking change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would lean on the side of no since TryLockError in the poison module has been around since 1.0 and it has never needed more variants than Poisoned and WouldBlock?

connortsui20 and others added 5 commits July 26, 2025 13:09
Adds the equivalent `nonpoison` types to the `poison::mutex` module.
These types and implementations are gated under the `nonpoison_mutex`
feature gate.

Co-authored-by: Aandreba <[email protected]>
This commit simply helps discern the actual changes needed to test both
poison and nonpoison locks.
Adds tests for the `nonpoison::Mutex` variant by using a macro to
duplicate the existing `poison` tests.

Note that all of the tests here are adapted from the existing `poison`
tests.
@bors
Copy link
Collaborator

bors commented Jul 26, 2025

☔ The latest upstream changes (presumably #144488) made this pull request unmergeable. Please resolve the merge conflicts.

connortsui20 and others added 2 commits July 26, 2025 13:23
Blesses the ui tests that now have a name conflicts (because these
types no longer have unique names). The full path distinguishes the
different types.

Co-authored-by: Trevor Gross <[email protected]>
Also cleans up some other test documentation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants