<mutex>: Scope guards for lock algorithms and exception specification strengthening
#3321
Conversation
And exception specification strengthening.
CaseyCarter
left a comment
There was a problem hiding this comment.
I lied: found something to change =)
We should never allow implicit conversions.
| _RERAISE; | ||
| _CATCH_END | ||
|
|
||
| _Guard._Valid = false; |
There was a problem hiding this comment.
No change requested: This is a perfectly cromulent name. However, it looks a little strange to say "this guard is invalid now", which sounds bad, but it's actually for the successful path. I would have recommended naming this _Active, as this would then read "this guard is inactive now", with more neutral connotations.
|
Thanks, these transformations look exactly correct, and bring us one step closer to the goal of eliminating unnecessary FYI @CaseyCarter @strega-nil-ms I added a couple of |
|
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
|
Thanks again for these nontrivial changes, improving debug codegen and debuggability! ✅ 😸 🎉 |
This PR changes
_RERAISEin<mutex>to scope guards (towards #2307).And strengthens exception specifications for
_Mutex_base::unlock(i.e.mutex::unlockandrecursive_mutex::unlock), andunique_lock("reverting LWG-2104", addressing Mark constructors that do not throw exceptions as noexcept #3278).