Mark LWG2731 as complete. The type alias mutex_type is only provided if
scoped_lock is given one mutex type and it has been implemented that
way since the beginning of Clang 5 it seems. There already are tests for
verifying existence (and lack thereof) for mutex_type type alias
depending on the number of mutex types, so there is nothing to
do for this LWG issue.
Details
- Reviewers
ldionne • Quuxplusone Mordante - Group Reviewers
Restricted Project - Commits
- rG7ad00511e4ab: [libc++][NFC] Mark LWG2731 as complete
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
libcxx/docs/Status/Cxx2bIssues.csv | ||
---|---|---|
14 | Despite the issue title, the issue is actually about scoped_lock, not lock_guard, and so I don't see how "5.0" could possibly be the right fix-version. |
libcxx/docs/Status/Cxx2bIssues.csv | ||
---|---|---|
14 | Well, scoped_lock was introduced in https://github.com/llvm/llvm-project/commit/6015dd11c875b9467c93221f19e5d59b0522757a (March 23rd, 2017) and then llvm5 got released on September 7th, 2017. Given that the mutex_type type alias was never an issue from its origin, that's why I dated this resolution back to 5.0. Would you prefer I just mark it as "Nothing to Do" and omit the version value? I don't feel strongly. I'd also be OK if you just want to label this as 14.0, but that doesn't feel quite right since there was no code change required in this patch. |
libcxx/docs/Status/Cxx2bIssues.csv | ||
---|---|---|
14 | OK; I didn't guess either that scoped_lock was that old or (more to the point) that LLVM 5 was that recent. We've been through 10 major version numbers in 4 years, eh. 😛 Then I'm OK with 5.0 here. |
Despite the issue title, the issue is actually about scoped_lock, not lock_guard, and so I don't see how "5.0" could possibly be the right fix-version.
Other than that, LGTM, ship it.