Differential D114034
[clang-tidy] fix debug-only test failure Authored by mattbeardsley on Nov 16 2021, 2:06 PM.
Details
The clang-tidy/infrastructure/pr37091.cpp test inherits the top-level .clang-tidy configuration because it doesn't specify its own checks. It'd be a more stable test if it operates independently of the top-level .clang-tidy settings. I've made the clang-tidy/infrastructure/pr37091.cpp test independent of the top-level .clang-tidy (picked an arbitrary check that I saw another clang-tidy/infrastructure test was also using: clang-tidy/infrastructure/temporaries.cpp)
Diff Detail
Event TimelineComment Actions @dstenb - wanted to check with you too to make sure that this change to pr37091.cpp seems like it won't interfere with the original intent of the test (https://reviews.llvm.org/D45686 ) The lingering file issue you'd fixed seemed to be independent of any particular clang-tidy check, but if not, hopefully it can at least get away with not relying on the top-level .clang-tidy anymore! Comment Actions Thanks for asking! Yes, I think that the issue was seen independently of the checks used. We saw that issue originally with clang-tidy invocations with explicit -checks arguments (specifying clang-analyzer-* and some more checks). So, I guess that just specifying some check here should be fine. Comment Actions Well, I've goofed. I was working in a shared fork where someone added a RenameFcn check locally (not sure we should be doing that, but that's besides the point). I thought I was in my vanilla llvm-project fork when I saw the failure. So some of the earlier messages don't apply. I still think it'd be good to isolate pr37091.cpp from the top-level .clang-tidy! But I've reverted the top-level .clang-tidy change. Comment Actions LG, thanks! I skimmed through the original patch and couldn't understand the RenameFcn part, thanks for the explanation! |