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?