[PATCH] D90180: [clang-tidy] find/fix unneeded semicolon after switch

Fri Nov 6 12:50:06 PST 2020

nickdesaulniers added a comment.

In D90180#2375878 <https://reviews.llvm.org/D90180#2375878>, @aaron.ballman wrote:

> In D90180#2374839 <https://reviews.llvm.org/D90180#2374839>, @nickdesaulniers wrote:
>
>> In D90180#2357247 <https://reviews.llvm.org/D90180#2357247>, @aaron.ballman wrote:
>>
>>> This will reduce the amount of compilation overhead for the clang-tidy project over time by not needing to introduce a new check (with new boilerplate) for each scenario but should hopefully still allow you to do what you need (with config files perhaps) in your CI. WDYT?
>>
>> I don't see how renaming the check changes "compilation overhead" or why we think "compilation overhead" of clang tidy is a concern in this case?
>
> I meant that if we had distinct checks `linuxkernel-switch-semi`, `linuxkernel-for-loop-semi`, `linuxkernel-middle-of-nowhere-semi`, etc that each one of those checks would require their own header file, source file, test files, documentation, etc. whereas if we had a single check, we'd reduce that overhead by only having one header, one source, one documentation, etc using config options, which makes fetching or building clang-tidy go ever-so-slightly faster.

Ah, so you're recommending that future checks related to additional/extraneous semicolons also be placed in this check, rather than their own?  I don't have a problem with that.

>> Maybe clarifying what you would prefer to see the check called and whether it would be in the linuxkernel namespace of checks or something else would help, @aaron.ballman ?
>
> I definitely think the check should live in the `linuxkernel` module. How about `linuxkernel-spurious-semi`, `linuxkernel-extra-semi`, `linuxkernel-remove-useless-semi-colons`, or anything that makes you happy and sounds similarly generic?

It's currently called `"linuxkernel-switch-semi"`, so if you'd like it to be slightly more generic, @trixirt would you mind renaming this check to something slightly more generic like one of the above (or something similar)?

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90180/new/

https://reviews.llvm.org/D90180