Looks correct clang-format to me.

@martong I don't have commit rights. Thanks for your help in advance.

Minor fixes for Aleksei's comments.

@a.sidorin what do you think?

Added @martong 's suggestions.

Updated to not conflict with and use the stuff implemented in https://reviews.llvm.org/D47445 (so became a bit smaller)
Now, it is ready for a review. Enjoy!

In D47946#1127679, @balazske wrote:

Problem: This change interferes with https://reviews.llvm.org/D47445. Probably that should be committed, it is approved already.

In D30691#954740, @george.karpenkov wrote:

I've tried using the patch, and I got blocked at the following: CTU options are only exposed when one goes through analyze-build frontend, which requires compile_commands.json to be present. I've used libear to generate compile_commands.json, but the generated JSON does not contain the command field, which causes @require before run to die (also, due to the passing style this error was unnecessarily difficult to debug).
So could you write a short documentation somewhere how all pieces fit together? What entry point should be used, what should people do who don't have a build system-generated compile_commands.jsonetc. etc.

The code modifications are coming soon (after doing some extensive testing) for the scan-build part.

Thanks George for the review. I will start working on the code right away. I've tried to answer the simpler cases.

Thank you guys!

removing non-conforming braces

Removing needless asserts and typos

ASTImporter unittests added.

Before abandoning this patch and rewriting it, I would like to get a thumbs up for my plans: I will reimplement all functionality included here but without creating a new checker. Some parts which relate to specific checkers will be put into the corresponding checkers (like ArrayBoundCheckerV2). General ideas on taintedness (cleansing rules and usage warnings on standard types) will be put into GenericTaintChecker. We will see how it goes, will we have a smaller patch or not. WDYT?

Better check not letting a real import problem passing through

Stepping back a bit, what do you consider "dirty" vs "clean"? It seems that you are looking for prove that the values are known to be within the bounds of min and max int values. What happens if there is a comparison to an unknown symbolic value? Should that be considered as clean or tainted? Are there test cases for this?

Hmm... I am thinking on this issue for a week now...

Hi, did you have time to check my changes?

So thank you again for the valuable questions.
In this checker, I give warnings for values which are both tainted and were also not checked by the programmer. So unlike GenericTaintChecker, I do implement the boundedness check here for certain, interesting constructs (which is controlled by the critical option). GenericTaintChecker focuses purely on taintedness, almost like a service for other checkers. I've added a new rule to it, improving the taintedness logic, but I felt mixing the bound checking logic into it would make the two ideas inseparable.

Thank you very much for your help. I've added all suggested modifications including tests covering all checker option settings.