Page MenuHomePhabricator

[clang-tidy] Factor out renaming logic from readability-identifier-naming
ClosedPublic

Authored by logan-5 on Jan 6 2020, 9:34 AM.

Details

Summary

Before this patch, readability-identifier-naming contained a significant amount of logic for (a) checking the style of identifiers, followed by (b) renaming/applying fix-its. This patch factors out (b) into a separate base class so that it can be reused by other checks that want to do renaming. This also cleans up readability-identifier-naming significantly, since now it only needs to be concerned with the interesting details of (a).

Diff Detail

Event Timeline

logan-5 created this revision.Jan 6 2020, 9:34 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 6 2020, 9:34 AM
Eugene.Zelenko added inline comments.Jan 6 2020, 10:05 AM
clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
352

Please elide braces. Same below.

I guess all the tests run?
I think this LGTM after the nits are adressed.

clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
204

What about the else? If it is unreachable it should have a llvm_unreachable("Reason");, if not, i think a little fallthrough comment wouldn't hurt.

260

Please add punctuation here and in the comments below.

JonasToth accepted this revision.Jan 6 2020, 12:34 PM
This revision is now accepted and ready to land.Jan 6 2020, 12:34 PM
logan-5 updated this revision to Diff 236449.Jan 6 2020, 1:50 PM
logan-5 marked 3 inline comments as done.

Addressed some nits. If the rest looks good, I'll need someone with commit access to help me wrap this up.

Eugene.Zelenko added inline comments.Jan 6 2020, 2:02 PM
clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
273

Please elide braces.

281

Please elide braces.

clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.h
48

It'll be reasonable to place all comments consistently: before definition or after.

95

Please use using. Same below. See modernize-use-using.

logan-5 updated this revision to Diff 236478.Jan 6 2020, 4:25 PM
logan-5 marked 3 inline comments as done.

More nits.

clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
273

Would you mind pointing me toward a resource for these formatting nits? I don't see anything about requiring omitting braces for single-statement if()s in the official LLVM coding standards (and I happen to think the braces actually help readability here). If this stuff is explicitly documented somewhere and painstakingly enforced like this, I'd rather get it right the first time.

aaron.ballman added inline comments.Jan 6 2020, 4:40 PM
clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
273

I looked through the coding standard and it does not suggest this, which I am really surprised to see (I feel like the standard used to say it at some point, but it likely got removed and I did not notice). This is a common pattern that's used all over the code base (likely from fairly consistent review guidance over the years), and so it's best to be consistent with the style used locally, but that's a pretty weak argument for new code.

logan-5 updated this revision to Diff 236483.Jan 6 2020, 5:10 PM
logan-5 marked 3 inline comments as done.

Consistent-ified single-statement-body control flow statements to not use braces.

JonasToth added inline comments.Jan 7 2020, 8:21 AM
clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
273

Did it maybe get dropped? Wasn't there are overhaul a few weeks ago? But I am surprised as well, as this was at one point explicitly stated.

i am still fine with the patch. if no one else has objections, i think this can land.

aaron.ballman added inline comments.Jan 7 2020, 8:46 AM
clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
273

I went as far back as the 4.0 coding standards and it wasn't listed in there, but I'm with you on remembering this being explicitly stated somewhere.

(Just in case this got lost in the shuffle)
If this looks good, (I think) I'll need someone with commit access to help wrap it up.

logan-5 updated this revision to Diff 238014.Jan 14 2020, 9:47 AM

Rebased with trunk.

njames93 added inline comments.Jan 14 2020, 10:51 AM
clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.h
29

Should this be protected as this class should never be instantiated directly. Also the definition could be moved inline as its just a delegating constructor

logan-5 marked an inline comment as done.Jan 14 2020, 11:15 AM
logan-5 added inline comments.
clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.h
29

The constructor (and destructor) can't be inline, since they need to be able to see the specialization of DenseMapInfo<NamingCheckId> in the cpp.

I could change it to protected to clean up the interface -- though it won't strictly change anything, since the class already has pure virtual functions so it's not instantiable.

logan-5 marked 2 inline comments as done.Jan 15 2020, 11:40 AM
logan-5 added inline comments.
clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.h
29

Searched the LLVM codebase for other abstract base classes with explicitly defined constructors (e.g. MakeSmartPtrCheck in clang-tidy), and their constructors seem to be public. I think I'll keep this one public too for consistency.

aaron.ballman closed this revision.Jan 16 2020, 1:35 PM

Thank you for the patch, I've commit on your behalf in d5c6b8407c12d39a78f42a216369407cb2d7b511