... then I have a script that runs clang-tidy over all the compilation units in a compilation database

Can you share this script please? :)

My point regarding statistics is that the check needs to pull its own weight -- if it doesn't find many true positives, it's not of much value to a broad community, or if it has a lot of false positives, we may need to tweak the check before releasing it to the public, etc. So definitely do the implementation work, but part of that work should be testing it over large code bases and reporting back the results.

Okay. Do we have any infrastructure for doing such testing? Or I should do it manually: prepare some large codebases, run over them clang-tidy with the check and parse the result?

@aaron.ballman Sure. I agree with you that epsilon should be configurable. I think we can collect some statistics later. Now I am going to work on implementation and tests. Later, of course, will be good to run the check on some codebases. I will be happy to hear that we already have some infrastructure for doing stuff like this.

One thing I would be interested in knowing is how often the check behaves when run over some large, real-world code bases. Does it catch any true positives? Does it have false positives?

I have no such statistics for this check. But I have statistics for identical check from PVS-Studio - https://www.viva64.com/en/examples/v624/

The main reason why I've created this differential - asking to you about usefulness of this check for clang-tidy. I understand that there are a some TODO and formatting issues - it's ok for now.

@JonasToth @NoQ @Szelethus can anyone merge it?

Can anyone merge it? I have no commit access

Can anyone help me with writing a checker for such code:

@hokein Is there any policy about the question "Which changes can clang-tidy check suggest?" . Should clang-tidy check suggest only "safe" fixes and warn only in "safe" cases?

Fix using auto in case where it leads to worse readability

1. Fix indentation in test file
2. Return back capitalization for the checker description

Sorry for necroposting - what is the status of the patch? @tvvikram

Which other changes and/or approvals are required for merging into trunk?

Hmm, i thought Clang has some warning for this, but I was wrong... Did you think to implement this check as Clang warning?

In D33672#1279305, @NoQ wrote:

Thanks! I like where this is going. Let's land the patch and continue developing it incrementally in trunk.

The next steps for this checker are, in my opinion:

• Do the visitor thingy that i requested in inline-311373. I think it's a necessary thing to do, but don't jump into implementing it right away: i already have some code for this that i want to share.
• Play nicely with typedefs. For now i believe the checker ignores them because you can't cast TypedefType to EnumType. Once this is done, it will be worth it to include the name of the enum in the warning message.
• Optimize the code using assumeInclusiveRange. Because assume is an expensive operation, i'd like to avoid doing it O(n) times for contiguous enums in which just 2 assumes are enough (or, even better, as single assumeInclusiveRange).
• See how this checker performs on real code, fix crashes and false positives if any.

Fix typedef -> using

Add new test for enum bit field

Add the reference to CERT page

1. Changed std::transform to llvm::transform
2. Described the check in .html file
3. Fixed RUN command for the test file

What is the status of the PR?