This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy][NFC] Move CachedGlobList to GlobList.h
ClosedPublic

Authored by carlosgalvezp on Nov 8 2021, 10:42 AM.

Details

Summary

Currently it's hidden inside ClangTidyDiagnosticConsumer,
so it's hard to know it exists.

Given that there are multiple uses of globs in clang-tidy,
it makes sense to have these classes publicly available
for other use cases that might benefit from it.

Also, add unit test by converting the existing tests
for GlobList into typed tests.

Diff Detail

Event Timeline

carlosgalvezp created this revision.Nov 8 2021, 10:42 AM
carlosgalvezp requested review of this revision.Nov 8 2021, 10:42 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 8 2021, 10:42 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
whisperity added inline comments.Nov 15 2021, 4:22 AM
clang-tools-extra/clang-tidy/GlobList.h
52–54

If CachedGlobList is-a GlobList, wouldn't it be better to express the inheritance relationship?

63

(considering the logically first data member is the conceptual base class)

carlosgalvezp added inline comments.Nov 15 2021, 5:51 AM
clang-tools-extra/clang-tidy/GlobList.h
52–54

Yes, that makes total sense to me. I wasn't sure if it was OK to do the move + change the code itself in the same patch. Will fix!

carlosgalvezp added inline comments.Nov 15 2021, 6:37 AM
clang-tools-extra/clang-tidy/GlobList.h
52–54

On the other hand, do we intend to use the class polymorphically? I wonder if private inheritance would be a better choice. Otherwise I'll need to start making the functions virtual and so on.

  • Replace composition with private inheritance.
  • Fix namespaces.

Public inheritance is not possible due to the base class' function being const-qualified; the derived class cannot be const since it updates state (unless we go into mutable territory, which I think goes in detriment of readability). What do you think?

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

Kind ping to reviewers.

Switch to public inheritance + mutable cached data. This seems to be a valid use case for mutable, even though I'm not sure if there's anything against it in the LLVM coding guidelines. Looking forward to your feedback!

Will aim to review and come back to you in a couple of days.

salman-javed-nz accepted this revision.EditedDec 3 2021, 2:31 PM

LGTM. The use of mutable with public inheritence is all over the clang-tools-extra code. See class SwapIndex : public SymbolIndex. I don't see why your use would be against the norm.

This revision is now accepted and ready to land.Dec 3 2021, 2:31 PM
This revision was automatically updated to reflect the committed changes.

Thanks a lot for the review!

Was there any real use case for making this polymorphic, The overhead for a virtual function call seems a little unnecessary IMO?

Was there any real use case for making this polymorphic, The overhead for a virtual function call seems a little unnecessary IMO?

Nothing other than readability, CachedGlobList is a GlobList so it made sense to implement it with standard, by-the-book inheritance. But no, it's not used polymorphically at the moment so technically virtual could be removed, even though it would probably go against developer expectations and might cause confusion for the above reasons in the future. Perhaps doing private instead of public inheritance (is implemented in terms of) would communicate the design better in that case?

Do you have profiling data that shows how much overhead the virtual function call actually adds in this particular case? In the projects I've worked with this has typically been a micro-optimization done prematurely without profiling data that supported the need for it, so the benefit was negligible. It did cause a lot of headache to developers reading the code though.

Nothing other than readability, CachedGlobList is a GlobList so it made sense to implement it with standard, by-the-book inheritance. But no, it's not used polymorphically at the moment so technically virtual could be removed, even though it would probably go against developer expectations and might cause confusion for the above reasons in the future. Perhaps doing private instead of public inheritance (is implemented in terms of) would communicate the design better in that case?

Do you have profiling data that shows how much overhead the virtual function call actually adds in this particular case? In the projects I've worked with this has typically been a micro-optimization done prematurely without profiling data that supported the need for it, so the benefit was negligible. It did cause a lot of headache to developers reading the code though.

It's definitely negligible as reading globs isn't exactly a hot path, was more just an irk when i was looking over the code.