Details
- Reviewers
• Quuxplusone - Group Reviewers
Restricted Project - Commits
- rG940755515da6: [libc++] Add the std::views::common range adaptor
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
LGTM mod comments, all of which are nits, I think.
libcxx/test/std/ranges/range.adaptors/range.common.view/adaptor.pass.cpp | ||
---|---|---|
33 | It would be good to test a non-view type also (i.e. one where all_t<R> isn't R). Something like [UNTESTED] std::vector<int> v = {1, 2, 3}; auto r = std::views::common(v); ASSERT_SAME_TYPE(decltype(r), std::ranges::ref_view<std::vector<int>>); | |
89 | Also static_assert(!CanBePiped<std::vector<int>, decltype(std::views::common)>); or perhaps replace line 88 with static_assert( CanBePiped<int(&)[10], decltype(std::views::common)>); static_assert(!CanBePiped<int(&&)[10], decltype(std::views::common)>); static_assert(!CanBePiped<int, decltype(std::views::common)>); | |
94 | Not only that, but std::addressof(std::views::common) == std::addressof(std::ranges::views::common). | |
libcxx/test/std/ranges/range.adaptors/range.common.view/types.h | ||
112 | If this noexcept is needed, something is wonky. Ditto on line 124. | |
116 | For my own information: Are the multiple overloads actually needed? I do have some vague recollection that they might be, for some poison-pill-related reason, but if so, geez, that's awful. :P |
libcxx/test/std/ranges/range.adaptors/range.common.view/adaptor.nodiscard.verify.cpp | ||
---|---|---|
12 ↗ | (On Diff #374901) | Question: since this is a libc++ extension, should we move this file into libcxx/test/libcxx for example? |
Address review comments. Thanks!
libcxx/test/std/ranges/range.adaptors/range.common.view/adaptor.nodiscard.verify.cpp | ||
---|---|---|
12 ↗ | (On Diff #374901) | Yes, the convention would be to put those in libcxx/test/libcxx. However, I've been sort of on the fence about this recently, it feels easier and clearer to put those alongside the normal tests and just use REQUIRES: libc++ to express that it's a libc++ specific test. The benefits I see are that you don't have to search for tests in two directories, and also there's no risk of the folder hierarchies getting out of sync if they get moved around. I'll move it to libcxx/test/libcxx if you request it, otherwise I'll leave as-is. |
libcxx/test/std/ranges/range.adaptors/range.common.view/adaptor.pass.cpp | ||
33 | Good suggestion, done. I used <array> because it's constexpr friendly. | |
89 | I'm curious to understand why int(&&)[10] can't be piped? | |
94 | We're not supposed to be able to take the address of those so I think it's reasonable not to test for that. | |
libcxx/test/std/ranges/range.adaptors/range.common.view/types.h | ||
116 | Yes, they are necessary for the poison pill thing, and yes, it's awful. |
libcxx/test/std/ranges/range.adaptors/range.common.view/adaptor.nodiscard.verify.cpp | ||
---|---|---|
12 ↗ | (On Diff #374901) | FWIW, I'm OK leaving it where it is now alongside the other tests. I prefer that, but will point out we have some inconsistency it seems. We can clean it up at some point in the future if desired (I'd be in favor of it). |
libcxx/include/__ranges/common_view.h | ||
---|---|---|
112 | Shouldn't there be tests to verify the noexcept status of the adaptor? | |
libcxx/test/std/ranges/range.adaptors/range.common.view/adaptor.nodiscard.verify.cpp | ||
12 ↗ | (On Diff #374901) | But being a verify test already implies a libc++ test. I've seen those more often in the std directory. |
libcxx/test/std/ranges/range.adaptors/range.common.view/adaptor.nodiscard.verify.cpp | ||
---|---|---|
12 ↗ | (On Diff #374901) |
I think Louis's point makes sense; I'm fine with leaving .verify.cpp tests in the test/std/ directory, as long as the test runner — and all human contributors! — will understand that .verify.cpp implies "run only with Clang, and only with libc++."
|
libcxx/test/std/ranges/range.adaptors/range.common.view/adaptor.pass.cpp | ||
61 | Why introduce this typedef? Couldn't you just use NonCommonView throughout, below? | |
76–77 | Just kvetching for the record: I see no benefit to this newfangled approach over the old-school no-Result-typedef approach of auto result = partial(view); ASSERT_SAME_TYPE(decltype(result), std::ranges::common_view<std::ranges::transform_view<SomeView, decltype(f)>>); |
libcxx/test/std/ranges/range.adaptors/range.common.view/adaptor.pass.cpp | ||
---|---|---|
89 | Assuming I'm correct that int(&&)[10] can't be piped :) my intuition is that rvalues of non-borrowed-range types can never be piped. int(&&)[10] is not an lvalue reference type, and int[10] is not a borrowed-range type; Q.E.D. We aren't used to thinking about array rvalues in C++, but they're just like any other rvalue. See https://quuxplusone.github.io/blog/2021/08/07/p2266-field-test-results/#libreoffice-ostring for another example from like a month ago. | |
94 | I agree; but I meant that right now you're just testing that views::x and ranges::views::x have the same type; you're not actually testing that they are two different names for the same object (which is what we want). |
libcxx/test/std/ranges/range.adaptors/range.common.view/adaptor.nodiscard.verify.cpp | ||
---|---|---|
12 ↗ | (On Diff #374901) | Hmm I see my post was a bit terse. But I meant:
|
Address review comments, in particular fix the confusion with .verify.cpp.
libcxx/test/std/ranges/range.adaptors/range.common.view/adaptor.nodiscard.verify.cpp | ||
---|---|---|
12 ↗ | (On Diff #374901) | Okay, reading this discussion made me change my mind, I guess. There are some misconceptions. verify.cpp tests are *not* libc++ specific in spirit. verify.cpp tests are simply a type of test supported by the testing format, and I don't think it makes sense to tie them to a specific implementation of the C++ stdlib. Also, they are not Clang specific *in spirit*. It is true that we don't support them with any other compiler right now because we need a compiler that supports clang-verify, but in theory it would be conceivable to support verify.cpp tests for other compilers. There would also be issues with how to translate diagnostics and all, but my point is that in spirit there's nothing Clang or libc++ specific with those tests. So what I'm going to do is move those libc++ specific tests to libcxx/test/libcxx, and also do a pass at our existing tests to move the libc++ specific ones to the right location. |
libcxx/test/std/ranges/range.adaptors/range.common.view/adaptor.pass.cpp | ||
61 | Cause I wanted to capture the fact that it's just "some view" -- I didn't pick NonCommonView specifically, it could have been a CommonView too. | |
76–77 | In this case you're right because Result = ..... is long so I put it on its own line, but in general it does reduce duplication in the tests and it can be easier to read. I'm not strongly attached to it, but I kind of liked it when (I think) @cjdb mentioned it to me, so I started adopting it. I'll keep doing that unless we come to an agreement that it's inferior. | |
94 | I'll colocate those tests in an upcoming patch. |
libcxx/test/std/ranges/range.adaptors/range.common.view/adaptor.nodiscard.verify.cpp | ||
---|---|---|
12 ↗ | (On Diff #374901) | Thanks for the clarification and moving the appropriate tests. |
Shouldn't there be tests to verify the noexcept status of the adaptor?