This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] In TransformerClangTidyCheck, support option IncludeStyle.
ClosedPublic

Authored by ymandel on May 4 2020, 5:05 PM.

Details

Summary

The new option allows the user to specify which file naming convention is used
by the source code ('llvm' or 'google').

Diff Detail

Event Timeline

ymandel created this revision.May 4 2020, 5:05 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 4 2020, 5:05 PM
Herald added a subscriber: xazax.hun. · View Herald Transcript
gribozavr2 accepted this revision.May 4 2020, 11:46 PM

LGTM, but I don't understand why this option is called "SourceNamingStyle". Existing ClangTidy checkers call it "IncludeStyle".

This revision is now accepted and ready to land.May 4 2020, 11:46 PM

LGTM, but I don't understand why this option is called "SourceNamingStyle". Existing ClangTidy checkers call it "IncludeStyle".

Thanks for the review!

Good question. I'd planned to call it "IncludeStyle" only to discover that it is misnamed. We could keep the name for consistency if it's in widespread use, but given that (IMO) it is quite misleading, I'd prefer to avoid it. At least to me, the name (and its description "A string specifying which include-style is used, llvm or google. Default is llvm.") implies that it controls how the includes are formatted. How they are grouped and ordered, for example. Yet, they don't. The IncludeSorter groups and orders the headers in exactly the same way no matter the style specification. It's only effect is to determine how a given file is related to header files, specifically how to determine that a header "corresponds" to a the file being examined -- that is, it is _this_ file's header rather than some arbitrary header. So, I figured that "SourceNamingStyle" captures this difference.

WDYT?

It's only effect is to determine how a given file is related to header files, specifically how to determine that a header "corresponds" to a the file being examined -- that is, it is _this_ file's header rather than some arbitrary header.

... and the results of that algorithm directly affect how the includes are sorted. We could also conceivably get more styles in IncludeSorter that affect how headers are sorted (for example, related to case sensitivity).

Although I personally don't think this option is misnamed, I can see your point though. But given that the current name is used in many existing checkers, I don't think we should diverge in this patch. I think the right way would be to rename the option consistently everywhere, and to maintain a compatibility alias with a warning for at least one release.

It's only effect is to determine how a given file is related to header files, specifically how to determine that a header "corresponds" to a the file being examined -- that is, it is _this_ file's header rather than some arbitrary header.

... and the results of that algorithm directly affect how the includes are sorted. We could also conceivably get more styles in IncludeSorter that affect how headers are sorted (for example, related to case sensitivity).

Sure, but the option itself isn't changing the style, even it influences the output. Agreed, though, that we could concievably leverage this to actually control details of the underlying algorithm, as you suggest. Although, I think the right answer is just to leave it all to clang-format.

Although I personally don't think this option is misnamed, I can see your point though. But given that the current name is used in many existing checkers, I don't think we should diverge in this patch. I think the right way would be to rename the option consistently everywhere, and to maintain a compatibility alias with a warning for at least one release.

Will do. I'm fine w/ maintaining consistency.

<rant>
I think a lot of my frustration stems from lost time trying to write tests against what I assumed was the behavior and then more time digginging into the code to actually determine the behavior (because it was only vaguely documented). Worse, IncludeSorter seems to have a bug for a corner case that probably only arisese naturally in tests -- if you add two headers to a file w/o any existing headers, it always adds them in the order recieved and separates them into different blocks. So, this experience left me with likely an overly strong aversion to the name. :)
</rant>

ymandel updated this revision to Diff 262105.May 5 2020, 7:31 AM

renamed option to IncludeStyle, for consistency w/ existing checks.

ymandel retitled this revision from [clang-tidy] In TransformerClangTidyCheck, support option SourceNamingStyle. to [clang-tidy] In TransformerClangTidyCheck, support option IncludeStyle..May 5 2020, 7:46 AM
This revision was automatically updated to reflect the committed changes.