-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
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
Conversation
b45b493 to
deda5c5
Compare
This comment has been minimized.
This comment has been minimized.
deda5c5 to
19b1a2c
Compare
This comment has been minimized.
This comment has been minimized.
19b1a2c to
a259232
Compare
This comment has been minimized.
This comment has been minimized.
e130930 to
804d305
Compare
804d305 to
b615348
Compare
|
r? tgross35 |
35fc4df to
71395b1
Compare
tgross35
left a comment
There was a problem hiding this 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)
|
@bors r- ^ For whatever that is, it's already tested and merged |
Continuation of #134663
Tracking Issue: #134645
This PR implements a new
sync/nonpoisonmodule, as well as thenonpoisonvariant of theMutexlock.There are 2 main changes here, the first is the new
nonpoison::mutexmodule, and the second is themutexintegration tests.For the
nonpoison::mutexmodule, I did my best to align it with the current state of thepoison::mutexmodule. This means that several unstable features (mapped_lock_guards,lock_value_accessors, andmutex_data_ptr) are also in the newnonpoison::mutexmodule, 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::mutexfile is essentially identical in spirit, as we are simply removing the error case from the originalpoison::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 othernonpoisonlocks when they eventually get implemented, but I'll leave that for a later discussion.