This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] fix debug-only test failure
ClosedPublic

Authored by mattbeardsley on Nov 16 2021, 2:06 PM.

Details

Summary

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 Timeline

mattbeardsley created this revision.Nov 16 2021, 2:06 PM
mattbeardsley requested review of this revision.Nov 16 2021, 2:06 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 16 2021, 2:06 PM

@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!

@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!

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.

mattbeardsley edited the summary of this revision. (Show Details)

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.

kbobyrev accepted this revision.Nov 18 2021, 2:53 PM

LG, thanks! I skimmed through the original patch and couldn't understand the RenameFcn part, thanks for the explanation!

This revision is now accepted and ready to land.Nov 18 2021, 2:53 PM

@dstenb Thanks for the confirmation!

@kbobyrev Sorry about my mixup! Would you be able to help me commit this?

This revision was automatically updated to reflect the committed changes.

@dstenb Thanks for the confirmation!

@kbobyrev Sorry about my mixup! Would you be able to help me commit this?

Done! Thank you for the patch!