- The reference type of common_input_iterator<const int*> can't be int&, because an lvalue of type const int _can't_ bind to an int&. Fix by changing the return type of operator* to decltype(auto) to make it fully generic.
- range.zip/iterator/compare.pass.cpp verifies that the iterators of a zip_view don't support <=> when the underlying iterators do not; this is not true after LWG-3692.
- libc++ doesn't yet implement P2165R4 "Compatibility between tuple, pair and tuple-like objects", so the tests expect zip_view to use pair in places where the working draft requires tuple.
Details
- Reviewers
huixie90 philnik - Group Reviewers
Restricted Project - Commits
- rGad41d1e26b12: [libc++][test] zip_view test cleanups
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
libcxx/test/std/ranges/range.adaptors/range.zip/cpo.pass.cpp | ||
---|---|---|
66 | Maybe guard this on defined(__cpp_lib_tuple_like) && __cpp_lib_tuple_like >= 202207L? | |
libcxx/test/std/ranges/range.adaptors/range.zip/types.h | ||
305–325 | Maybe we should lift this into test_iterators.h. This seems like the kind of thing that gets duplicated very easily. |
libcxx/test/std/ranges/range.adaptors/range.zip/ctor.default.pass.cpp | ||
---|---|---|
53–60 | In theory I guess we should check the feature test macro __cpp_lib_tuple_like, but I think I prefer your solution. We are going to implement the paper without supporting the previous behaviour. so after implementing the paper, a test failure would be preferable over silently selecting another branch. | |
libcxx/test/std/ranges/range.adaptors/range.zip/types.h | ||
322 | Thanks for the fix. I think this function is not used in the tests. The main usage of this class is to test the end function returns the correct type and compares with the iterator correctly (without calling operator*) |
libcxx/test/std/ranges/range.adaptors/range.zip/cpo.pass.cpp | ||
---|---|---|
66 | As Hui commented below, the intent isn't to keep both alternatives. My intent is that these tests break loudly upon implementing P2165R4 so someone will open them up and remove the "old" code instead of leaving it dead. We could equivalently have _only_ the P2165R4 behavior and XFAIL these tests for libc++ but I prefer to validate the "wrong" behavior for the time being to defend against regressions that would cause the test to fail but in a different way. Full disclosure: MSVCSTL has been implementing P2165 piecemeal, so we don't define the feature-test macro yet. Guarding with the macro wouldn't accomplish my goal of getting all of these tests up on MSVC. | |
libcxx/test/std/ranges/range.adaptors/range.zip/ctor.default.pass.cpp | ||
53–60 | I argue for this approach in some detail in my response to Philnik's comment above. | |
libcxx/test/std/ranges/range.adaptors/range.zip/types.h | ||
322 | I used auto& to conservatively make this "just generic enough to cover existing uses" but I agree that full decltype(auto) is more completely future-proof. |
libcxx/test/std/ranges/range.adaptors/range.zip/types.h | ||
---|---|---|
305–325 | I'd prefer to land this as-is and leave any such code motion to a followup PR. |
Maybe guard this on defined(__cpp_lib_tuple_like) && __cpp_lib_tuple_like >= 202207L?