If both flags created through BoolOption are CC1Option and the keypath has a non-default or non-implied value, the denormalizer gets called twice. If the denormalizer has the ability to generate both flags, we can end up generating the same flag twice.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/unittests/Frontend/CompilerInvocationTest.cpp | ||
---|---|---|
272 | Is it wise to rely on pointer comparison here? The call to count returns 2 before changing the denormalizer and 1 after, but I'm not sure if it will work on all platforms. |
clang/unittests/Frontend/CompilerInvocationTest.cpp | ||
---|---|---|
272 | Does this compile / avoid the pointer comparison? ASSERT_EQ(count(GeneratedArgs, StringRef("-fdebug-pass-manager")), 1); |
clang/unittests/Frontend/CompilerInvocationTest.cpp | ||
---|---|---|
272 | Yes, this forces the const char * from GeneratedArgs to be converted into StringRef, which does comparison via ::memcmp. If we decide comparing StringRefs is a better solution, I'd be inclined to create a helper function or custom matcher that does the conversion to StringRef. That way, we don't have to worry about doing the right thing in test cases. |
lgtm with the test fix.
clang/unittests/Frontend/CompilerInvocationTest.cpp | ||
---|---|---|
272 | I believe that if you have shared libraries enabled this is guaranteed to be different. We should do a string comparison here, and I think a helper makes sense if we expect to do this more often. |
LGTM too, once the test is fixed.
clang/unittests/Frontend/CompilerInvocationTest.cpp | ||
---|---|---|
272 | Agreed, should be string comparison. IMO passing StringRef("...") into count is clear / easy enough, but a custom matcher would be fine too. |
Is it wise to rely on pointer comparison here? The call to count returns 2 before changing the denormalizer and 1 after, but I'm not sure if it will work on all platforms.