Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I'm not sure why this is necessary, given that only one function is calling the each of the strchr implementations, and they're each less than 10 lines of code. Do you plan to call these in more functions? If you are, would putting these implementations in string_utils.h make sense instead?
For child revision D147464. Regarding string_utils.h, why is that preferred over memory_utils/? I'm happy to do it, I forgot that header existed which is why I added it to string_utils. But I am curious why it is preferred
Generally, memory_utils/ is used for optimized memory functions and is managed by @gchatelet. The string_utils.h file has the implementations for functions focused on null terminated strings and is managed by me.
Given that the followup patch does add more uses for these functions, I see this as a worthwhile change, though I'd suggest making the internal function work like strchrnul. That will let you implement both strchrnul and strchr with the same internal function and only minor additional code.
Given that the implementations are small and standard C++ I would move them as part string_utils rather than memory_utils as @michaelrj suggested.
libc/test/src/string/StrchrTest.h | ||
---|---|---|
158 | It'd rather see templated tests rather than macros. They tend to be harder to debug and they impede readability and formatting. |
libc/test/src/string/StrchrTest.h | ||
---|---|---|
158 | Are you referring to gtest typed tests? |
libc/test/src/string/StrchrTest.h | ||
---|---|---|
158 | Yes absolutely. I've used them in https://github.com/llvm/llvm-project/blob/main/libc/test/src/string/memory_utils/op_tests.cpp |
libc/test/src/string/StrchrTest.h | ||
---|---|---|
158 | I guess I don't understand how that would look like other than something like: strchr_test.cpp #define FUNC Strchr struct FuncT { static constexpr auto Func = __llvm_libc::strchr; }; #include "StrchrTest.h" and StrchrTest.h #define TEST_NAME_(LEFT, MIDDLE, RIGHT) LEFT ## RIGHT #define TEST_NAME(NAME) TEST_NAME_(LlvmLibc, NAME, Test) TYPED_TEST(TEST_NAME(FUNC), FindsFirstCharacter, FuncT) { constexpr auto Func = ParamType::Func; const char *src = "abcde"; // Should return original string since 'a' is the first character. ASSERT_STREQ(Func(src, 'a'), "abcde"); // Source string should not change. ASSERT_STREQ(src, "abcde"); } ... Which I don't think is better. Unless you have something else in mind. This is what parameterized tests are for, but we don't have those. FWIW, the current code is how we already do these kinds of test sharing, mostly in math/. |
I see. The reason I am partial to not doing that is because then to test strchr you must also include index, and it is very likely you would only want the former. I haven't included it in non linux targets, nor have I added it to the bazel build.
Moreover, the common structure of src/$func.{cpp,h} and test/src/$func_test.cpp makes downstream build infrastructure much easier when all functions follow the same pattern than multiple functions sharing a single test file.
While I like the idea of avoiding macros, I think it's more important for the tests to be independent of which entrypoints are included. This patch looks good to me.
libc/test/src/string/StrchrTest.h | ||
---|---|---|
158 | TYPED_TEST is problematic since it's not supported by the other compatible-enough test frameworks where these tests are built, such as Fuchsia's zxtest. I think the tolerable middle ground that makes the boilerplate at least less annoying while avoiding macros is to rely on the fixture as done here to keep the actual test logic common and just template-parameterized with the actual function pointer, but then write out both copies of all the TEST_F(LlvmLibcStrchrTest, ...) and TEST_F(LlvmLibcIndexTest, ...). We can see in the future if using TYPED_TEST here can be made feasible, but it's just not yet. I'd like to get this unblocked and land some version of this so we can get index and rindex landed. |
Sorry for the delayed response.
I missed the requirement that the tests should be independent. Given that the build system decides which functions are to be tested, it's difficult to use the templated approach I was suggested.
LGTM
It'd rather see templated tests rather than macros. They tend to be harder to debug and they impede readability and formatting.
If you follow @michaelrj advice you won't have to duplicate the tests.