Macro-generated long switches: I cannot access the check results right now, but if I recall correctly, the check assigned these errors to certain lines in the .inc files. This means that (1) it is not very easy to to suppress them with //NOLINT comments, but (2) it should be relatively easy to filter them by location (ignore all reports coming from .inc file).

I applied this check to the llvm + clang codebase, and I was surprised to see that it produced about 600 results (for comparison, the clang-tidy checks which are enabled by default produce approximately 6000 results together). I didn't go through the whole list, but after examining a few dozen random reports it seems that most of these are true positives: relatively short branches (usually one or two lines of code) are repeated for no obvious reason. I would guess that most of these fall into the "correct but too verbose" case, because otherwise the tests would have caught the problem, but I didn't try to understand their context.

Minor correction in documentation

At the end of the documentation I stated that the check examines the code after macro expansion. Is this note clear enough?

Handle ternary operators, improve documentation

Correct a typo (ELSE instead of else)

I looked at the AstDiff library, but I think that it is overkill for my goals. The main feat of the AstDiff library is analyzing and presenting the differences between two AST subtrees, while this checker only needs a simple yes/no answer for "Are these branches identical?".

Minor simplifications, add tests for macro handling

I will add tests for macro handling later.

Remove braces, move if parent checking to ASTMatcher, other minor improvements

An example of duplicated code in Clang (it appears in llvm/tools/clang/lib/Frontend/Rewrite/RewriteMacros.cpp starting from line 128):

Implement suggested improvements

Could someone with commit rights commit this patch (if it is acceptable)? I don't have commit rights myself.

Use ASTContext::getFloatTypeSemantics()

I found a solution for determining the precision value of a floating point type. Is this acceptable?

Use APFloat to determine precision of floating point type

Give a reference for the significand size values of the IEEE 754 floating point types; cleanup comments and formatting.

polite ping

What would happen if this checker encounters a variadic macro (introduced to the standard in in C++11, see syntax (3) and (4) here) or the # and ## preprocessor operators?

Fix formatting in tests; add a comment.

I don't have commit rights, please commit for me @NoQ or @martong

I submitted a new patch, which moves stdCLibraryFunctions to apiModeling (https://reviews.llvm.org/D52722).

Yes, moving StdCLibraryFunctionsChecker to an always-loaded package is probably a better solution than adding this one particular dependency link. (Evaluating these functions may be useful for other checkers as well, although it does not seem to change the results of other regression tests.) As an alternative to moving this checker to either the core or the apiModeling package, we could add unix.StdCLibraryFunctions to the dozen or so loaded-by-default checkers listed in lib/Driver/ToolChains/Clang.cpp without moving it to a different package. Which of these options is the best?