Details
- Reviewers
ldionne Mordante - Group Reviewers
Restricted Project - Commits
- rG43e421417378: [libc++] [C++2b] [P1682] Add to_underlying.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
libcxx/include/utility | ||
---|---|---|
1636 | Would it be possible to make it available for earlier versions? I like to use this in D97115? I'm aware we're reluctant to offer features to earlier versions. | |
1638 | The inline isn't needed. | |
libcxx/test/std/utilities/utility/utility.underlying/to_underlying.pass.cpp | ||
24 | Maybe interesting to also test these bounds for an plain enum. | |
28 | This isn't used in the tests below. | |
libcxx/utils/generate_feature_test_macro_components.py | ||
598 | The paper has no number. Is it certain this will be the final value? |
libcxx/test/std/utilities/utility/utility.underlying/to_underlying.pass.cpp | ||
---|---|---|
28 | A yes my bad. |
Address review comments:
- Remove unnecessary inline.
- Add plain enum tests.
- Expose __to_underlying in C++14 onwards.
libcxx/include/utility | ||
---|---|---|
1636 | Would this be OK? | |
libcxx/utils/generate_feature_test_macro_components.py | ||
598 | I'm pretty sure it will be the final value, since another feature approved in the same meeting uses this value. Cf. https://github.com/cplusplus/draft/pull/4515/files#diff-f46371f476893d323cfcb1383e9a70f07ff1c1f0c217e22294d0bf937aae6794R696. |
libcxx/include/utility | ||
---|---|---|
1647 | I wish we had using to_underlying = __to_underlying;. |
One small request otherwise LGTM.
libcxx/include/utility | ||
---|---|---|
1640 | Since we also use bitmask types in C++11, would it be possible to make this available in C++11? std::underlying_type is available in C++11. | |
libcxx/utils/generate_feature_test_macro_components.py | ||
598 | Sounds good enough to me. If it's wrong it's also trivial to fix. |
libcxx/utils/generate_feature_test_macro_components.py | ||
---|---|---|
598 | I see there's a PR for this paper using 202102L so this looks good. https://github.com/cplusplus/draft/pull/4526/commits/47fd349eef8e4bdf5cdaed9513505f903d5e8f38 |
libcxx/include/utility | ||
---|---|---|
1632 | I can't, it's C++14 onwards. #if _LIBCPP_STD_VER > 11 template <class _Tp> using underlying_type_t = typename underlying_type<_Tp>::type; #endif | |
libcxx/test/std/utilities/utility/utility.underlying/to_underlying.fail.cpp | ||
9 ↗ | (On Diff #326613) | Hmm, when all compilers we support will accept -std=c++20? |
libcxx/include/utility | ||
---|---|---|
1640 | Your friendly neighborhood ADL-hater says: _VSTD::__to_underlying | |
libcxx/test/std/utilities/utility/utility.underlying/to_underlying.fail.cpp | ||
9 ↗ | (On Diff #326613) | My (untested) impression is that
|
libcxx/test/std/utilities/utility/utility.underlying/to_underlying.pass.cpp | ||
62 | I would be interested to see how std::to_underlying(s.bf) works on an enum bit-field. I know that's more of a core-language-trivia issue than a library-trivia issue, but it'd still be nice to have a test case. And if you can construct a test case for the ADL issue (maybe involving enum X<Holder<Incomplete>>::E? I'd have to look up the rules again), that'd be cool (but not a blocker). |
libcxx/test/std/utilities/utility/utility.underlying/to_underlying.pass.cpp | ||
---|---|---|
62 | Done. |
libcxx/include/utility | ||
---|---|---|
1632 |
I asked for C++11 support so I can use it in D97115. | |
libcxx/test/std/utilities/utility/utility.underlying/to_underlying.fail.cpp | ||
9 ↗ | (On Diff #326613) | There's already support for c++2b. Personally I don't mind 2a in our tests and once all supported platforms support -std=c++20 we can change it in one go. Or would you also prefer to use 23 already? I get the impression the Standard committee feels more comfortable about their 3 year schedule and are already using C++23 instead of C++2b. (Note I'm not a member of the committee.) |
libcxx/test/std/utilities/utility/utility.underlying/to_underlying.fail.cpp | ||
---|---|---|
9 ↗ | (On Diff #326613) | I think that llvm-lit should add support for --param std=c++20 on the same day that Clang adds support for -std=c++20. (This will require llvm-lit to understand that on certain kinds of buildbots, --param std=c++20 translates into -std=c++2a; but I think this must be a small change, because it already needs to understand that on certain kinds of buildbots, --param std=c++20 simply doesn't work at all.) Severably, I think that Clang should add support for -std=c++2b on the same day that Clang adds support for -std=c++20. Severably, I think that llvm-lit should add support for -std=c++2b on the same day that llvm-lit adds support for -std=c++20. Of course the horse has already left the barn on all of these bullet points. But translate them all up by 3 (2a->2b, 20->23, 2b->2c) and they describe what I think should happen in the future. I think there should be a "deploy plan" for going from 17/2a, to 17/20/2b, to 17/20/23/2c, and each time it's executed it should be executed relatively atomically, without months or years of dangling loose ends. The situation described in https://stackoverflow.com/a/56483887/1424877 is pretty embarrassing for all three compiler vendors, IMO. |
Code LGTM (modulo please remove the ADL test).
I'm not sure I understand the state of the world re: has this landed in C++2b yet? do we run C++2b tests yet? and is it March 8 yet? ;) so I don't want to be the one to say "accept". But I'm unlikely to have any further review comments, and certainly have no desire to block this if someone else wants to accept it.
libcxx/test/std/utilities/utility/utility.underlying/robust_against_adl.pass.cpp | ||
---|---|---|
42 ↗ | (On Diff #328225) | I don't think this is a reasonable thing to test; the user can't do this. (At least, if they do, we should laugh in their face.) I believe I've convinced myself that there is no way to write a test for this VSTD-qualification. The only associated type of an enum is the-class-of-which-it-is-a-member, and that class must already be complete, by definition, so we can't use the Holder<Incomplete> trick to hard-error on completing it. Of course you should still do the VSTD-qualification, for consistent libc++ style if nothing else. But I strongly vote for removing this robust_against_adl test, because it does things (reopening namespace std) that the user really isn't allowed to do. |
So, yes we do test in C++2b mode, for a few weeks at least already.
And yes, it has been approved for C++2b. The draft is not yet updated, but there is a PR for that (https://github.com/cplusplus/draft/pull/4526).
And, I'll remove the ADL test.
libcxx/test/std/utilities/utility/utility.underlying/robust_against_adl.pass.cpp | ||
---|---|---|
42 ↗ | (On Diff #328225) | Agreed. |
If the paper has been voted into the Standard, then I think it's fine for us to implement it. It seems to be the case, so let's ship it.
Apart from that and the other minor comments by reviewers, I think this is good to go.
libcxx/include/utility | ||
---|---|---|
1640 | Just to be clear, we don't provide new features in older standard modes. It's fine to expose __to_underlying pre C++2b so you can use it to implement other stuff, but it has to come at no significant additional cost (OK here). But we *do not* expose std::to_underlying pre C++2b -- not sure which one you were asking about. | |
libcxx/test/std/utilities/utility/utility.underlying/to_underlying.fail.cpp | ||
9 ↗ | (On Diff #326613) | The Lit issue will *soon* become moot once we stop supporting older compilers anyway. I suggest we don't do anything about this and just pinch our nose for a couple more months. |
1 ↗ | (On Diff #328225) | This should be a .verify.cpp test instead! |
- Remove ADL test.
- Rename fail -> verify.
libcxx/include/utility | ||
---|---|---|
1640 | Yes, the idea was to expose __to_underlying (but not std::to_underlying) in pre C++2b, so that it can be used for bitmask types. |
libcxx/include/utility | ||
---|---|---|
1632 | Ah, thanks. Sorry, missed that. |
Nit: you could use underlying_type_t here.