The tests for std::ranges::lazy_split_view heavily use a wrapper class around
std::string because std::string was not constexpr until recently. Where
possible, remove the wrapper class and extra functionality no longer needed.
Remove libcxx/test/std/ranges/range.adaptors/range.lazy.split/small_string.h
and inline its one use remaining in
libcxx/test/std/ranges/range.adaptors/range.lazy.split/general.pass.cpp.
Details
- Reviewers
var-const philnik Mordante ldionne - Group Reviewers
Restricted Project - Commits
- rGae2ae84ffed3: [libc++][test] Refactor SmallBasicString uses in range.lazy.split tests
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
LGTM % nit, but I think @var-const should take a look here.
libcxx/test/std/ranges/range.adaptors/range.lazy.split/ctor.range.pass.cpp | ||
---|---|---|
74–75 | I think it makes more sense to replace the occurrences of StrRange with std::string. Ditto for string_view. |
libcxx/test/std/ranges/range.adaptors/range.lazy.split/ctor.range.pass.cpp | ||
---|---|---|
74–75 | I'm OK with that. I was debating whether to even touch this at all in this patch (I could have added a base() to the end of begin() and end() functions like I did elsewhere in this patch). Do you have a preference, @var-const? |
Fix CI for range.lazy.split/ctor.range.pass.cpp in C++20 mode. This is required since std::string_view constructor from a range only works in C++23 or later.
Rebase to see if the clang trunk (bootstrapping build) ICE goes away. Otherwise, I'll dig into it and report the Clang bug (likely)
Rebase to poke with newest Clang. I can repro the ICE on clang trunk, but it's not consistent. I think it's a miscompile by Clang in some cases.
You get a consistent failure if you run against an assertions-enabled build of clang. https://github.com/llvm/llvm-project/issues/55867
Nice minimal - much smaller than when we looked at it earlier today! Thanks, @davidstone.
I'll try a bit to workaround it, otherwise, we'll just wait for the Clang patch as it's a recent regression (works in Clang 14, for example).
Generally LGTM (and thanks a lot for doing this cleanup!), but I have a couple of questions -- perhaps we can clean up even more stuff, but if not, this patch looks pretty good already.
libcxx/test/std/ranges/range.adaptors/range.lazy.split/ctor.range.pass.cpp | ||
---|---|---|
74–75 | The current state looks good to me. | |
libcxx/test/std/ranges/range.adaptors/range.lazy.split/general.pass.cpp | ||
34 | What prevents replacing this class with std::string as well? | |
libcxx/test/std/ranges/range.adaptors/range.lazy.split/range.lazy.split.outer/deref.pass.cpp | ||
34 | Why is calling equal necessary instead of ==? |
libcxx/test/std/ranges/range.adaptors/range.lazy.split/general.pass.cpp | ||
---|---|---|
34 | I think it's the different types of things we're working with the Char and Str types in is_equal function template. Specifically, the family of types it takes on is "stringlike" but we take advantage of that extra layer of conversion when constructing the BasicSmallString (note the three different constructors all of which we use - specifically when going from a string_view-like type to a string for example). I played with it for a while and didn't find a way to remove the dependency. I do recommend you or @philnik play with it as a follow up for a bit to see if you come up with something clever as you're both more knowledgable in the ranges area. I really would like to get rid of is_equal entirely and just use std::ranges::equal, but the default projection won't work for similar reasons as to why we have BasicSmallString to begin with (and the view type's iterator/sentinel won't satisfy input_range needed for std::ranges::equal). | |
libcxx/test/std/ranges/range.adaptors/range.lazy.split/range.lazy.split.outer/deref.pass.cpp | ||
34 | There's no valid operator== now. The error is: libcxx/test/std/ranges/range.adaptors/range.lazy.split/range.lazy.split.outer/deref.pass.cpp:35:15: error: invalid operands to binary expression ('std::ranges::lazy_split_view<ForwardDiffView, ForwardDiffView>::__outer_iterator<false>::value_type' and 'basic_string<char>') assert(*i == "abc"s); In the previous code, it worked because of constexpr bool operator==(const BasicSmallString& lhs, std::string_view rhs) in small_string.h if I understand correctly. Now that we removed SmallString, we don't have that comparison operator. Similar story in the other call sites that were made to use std::ranges::equal. Does that make sense? |
Although the ranges::equal aren't perfect I think this is an improvement overall, so LGTM. We can further improve the tests in other patches if we want.
libcxx/test/std/ranges/range.adaptors/range.lazy.split/range.lazy.split.outer/deref.pass.cpp | ||
---|---|---|
34 | Ah, right, basically dereferencing returns some helper type instead of a string, and we don't have the constructor taking a range for std::string yet. Thanks for explaining. |
I think it makes more sense to replace the occurrences of StrRange with std::string. Ditto for string_view.