This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] Fix a couple additional cases in misc-use-anonymous-namespace
ClosedPublic

Authored by carlosgalvezp on Dec 1 2022, 6:59 AM.

Details

Summary
  • Do not analyze header files, since we don't want to promote using anonymous namespaces there.
  • Do not warn about const/constexpr variables, those are implicitly static in C++ and they don't need to be moved to an anonymous namespace. Warning about redundant static in general could be implemented as a standalone check, moving away some of the functionality from this check.

Diff Detail

Event Timeline

carlosgalvezp created this revision.Dec 1 2022, 6:59 AM
Herald added a project: Restricted Project. · View Herald Transcript
carlosgalvezp requested review of this revision.Dec 1 2022, 6:59 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 1 2022, 6:59 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

Fix naming convention

njames93 added inline comments.Dec 1 2022, 11:45 AM
clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.cpp
40

The logic would fall apart when run in clangd or unity builds. The safest way is generally to match the file extension, we have a class for it in clang-tidy/utils

clang-tools-extra/test/clang-tidy/checkers/misc/use-anonymous-namespace.cpp
35

These changes just look like noise.

Address comments

carlosgalvezp marked 2 inline comments as done.Dec 1 2022, 12:24 PM
carlosgalvezp added inline comments.
clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.cpp
40

Great suggestion, thanks!

carlosgalvezp marked an inline comment as done.

Add options for users to define their own header file
extensions.

Document ignored cases in the documentation.

Remove accidentally added newline.

I'm happy with my changes now, ready for a new round of review! :)

The LLVM coding style says to prefer static over anonymous namespaces.

clang-tools-extra/docs/clang-tidy/checks/misc/use-anonymous-namespace.rst
17

extensions

carlosgalvezp marked an inline comment as done.EditedDec 1 2022, 1:25 PM

The LLVM coding style says to prefer static over anonymous namespaces.

Yes, but this is not an LLVM check, it's a misc check. Other projects are allowed to have other guidelines.

carlosgalvezp retitled this revision from Fix a couple additional cases in misc-use-anonymous-namespace only to Fix a couple additional cases in misc-use-anonymous-namespace.
carlosgalvezp edited the summary of this revision. (Show Details)

Fix typo in commit message

carlosgalvezp retitled this revision from Fix a couple additional cases in misc-use-anonymous-namespace to [clang-tidy] Fix a couple additional cases in misc-use-anonymous-namespace.Dec 5 2022, 4:41 AM
vingeldal accepted this revision.Dec 12 2022, 5:01 AM
vingeldal added inline comments.
clang-tools-extra/test/clang-tidy/checkers/misc/use-anonymous-namespace.cpp
46–48

Is it really the best behavior to allow these? If I got the rationale right we don't warn about this because const and constexpr have implicit internal linkage anyway, so static doesn't make a difference, right?
Reading the documentation for this check I gather static would probably have been deprecated if it wasn't for the fact that deprecation would have broken compatibility with C. So, if we drop the static keyword here we still get the behavior we want, without a confusing keyword we would rather get rid of if we could, while keeping compatibility with C.

I'm thinking it could be better to just discourage from using static for cases like this.

This revision is now accepted and ready to land.Dec 12 2022, 5:01 AM
carlosgalvezp added inline comments.Dec 12 2022, 6:39 AM
clang-tools-extra/test/clang-tidy/checkers/misc/use-anonymous-namespace.cpp
46–48

Thanks for the review!

Yes, that example is "bad" code, but this particular check would currently ask users to move the variables to the anonymous namespace - which is also incorrect.

My plan is to add one more separate checks in the "readability" section that warn about redundant usages of 'static' (like this one), and even supports automatic fixes (which aren't possible in this check).