Thanks for the quick review!
Fixed the double backtick in the release notes as well.

Remove literal checking from the matcher for memset as well

fix Release Notes

Add full diff with arcanist

Added a release note
Also generated the full context (arcanist could validate the site certificate, that's why I had to resort to manual diff creation. Was there a certificate change on the reviews.llmv.org site maybe?)

{F23163926}
There is no change in the results as far as these OS projects are concerned.

add analyzer tag

@steakhal
This is WIP as there is still a stdlib function, that does not pass the test, and I would like to add more complex taint propagation test cases as well.
Could you please glance over these commits:
[Malloc] Pass down a State and a Pred ExplodedNode in the MallocChecker
[BoundV2][Malloc] Place NoteTags when allocated an interesting tainted amount of memory
[Stdlib] Add taint to the StdLibraryFunctionsChecker

• [BoolAssign] Add taint to the BoolAssignmentChecker
• [BugReporter] Transitive interestingness
• [Malloc] Pass down a State and a Pred ExplodedNode in the MallocChecker
• [BoundV2] ArrayBoundV2 checks if the extent is tainted
• [BoundV2][Malloc] Place NoteTags when allocated an interesting tainted amount of memory
• [CString] Add ConsiderTaint checker option for CStringChecker
• [CString] Consider tainted out-of-bound accesses
• [Stdlib] Add taint to the StdLibraryFunctionsChecker
• [Malloc] Implement the rsize_t like heuristic

rebase

• remove vscanf and co.
• use debug.ExprInspection for test cases
• fix semantic issues for modeled functions

fix readlinkat arg index
extend testcase for readlinkat

readlinkat fix incoming

add readlinkat
rename _IO_getc testcase

• s/getcw/getwd
• add gets_s
• remove getopt variants
• add realinkat
• discuss getnameinfo?
• rename tests
• update getnameinfo
• comment on source/propagator discrepancy
• update tests where 1 / tainted, and tainted cannot be 0
• renamed tests

Remove explicit template keyword for MSVC compatibility

All (except the last) commits were excluded in the previous patch upload

This is superseded by D116025.

Applied typo and naming fixes, introduced 2 move operations, and re-introduced short circuiting.

Fixes round two

Tidy things up thanks to the recommendations of @steakhal

Remove static asserts as it adds little to no value in this case

Remove static asserts as it only makes the tests more brittle

update with arc diff $(git merge-base HEAD upstream) --update D113251
in order to satisfy workflow pre-merge checks

fix indentation warning
make inline code formatting look better

tidy up based on comments from whispy

Fix the review comments of @steakhal

On bitcoin v0.18.1, there is an assertion introduced by this change.
The TU that can be used for reproduction is src/script/interpreter.cpp.
Assertion message:

CTU loaded AST file: /home/gamesh411/bitcoin/src/script/script.cpp                                                                                                                                         
clang: /home/gamesh411/llvm-project/clang/lib/AST/ASTContext.cpp:4411: clang::QualType clang::ASTContext::getInjectedClassNameType(clang::CXXRecordDecl*, clang::QualType) const: Assertion `NeedsInjectedC
lassNameType(Decl)' failed.

In D83717#2370154, @NoQ wrote:

I don't think you actually need active support for invoking exit handlers path-sensitively at the end of main() in order to implement your checker. You can still find out in a path-insensitive manner whether any given function acts as an exit handler, like you already do. Then during path-sensitive analysis of that function you can warn at any invocation of exit().

I do believe that you want to implement this check as a path-sensitive check as long as you want any sort of interprocedural analysis (i.e., warn when an exit handler calls a function that calls a function ... that calls a function that calls exit() - and you do already have such tests). This is because of the following potential situation:

void foo(bool already_exiting) {
  if (!already_exiting)
    exit();
}

void bar() {
  foo(true);
}

void baz() {
  foo(false);
}

int main() {
  atexit(bar);
  return 0;
}

In this case bar() is an exit handler that calls foo() that calls exit(). However the code is correct and no warning should be emitted, because foo() would never call exit() when called from bar() specifically. Precise reasoning about such problems requires path-sensitive analysis. Of course it's up to you to decide what to do with these false positives - whether you'll be ok with having them, or choose to suppress with an imprecise heuristic - but that's one of the possible reasons to consider reimplementing the checker via path sensitive analysis that the static analyzer provides.

We've had a similar problem with the checker that warns on calling pure virtual functions in constructors/destructors (which is undefined behavior). Such checker had to be path sensitive in order to be interprocedural for the exact same unobvious reason. We've decided to re-implement it with path-sensitive analysis and now we're pretty happy about that decision.

Just to make sure we're on the same page -- the current approach is not flow-sensitive, and so my concern is that it won't report any true positives (not that it will be prone to false positives).

Sorry about that. You are absolutely right; what I was trying to say is CallGraph-based.

In D83717#2279263, @aaron.ballman wrote:

One of the concerns I have with this not being a cfg-only check is that most of the bad situations are not going to be caught by the clang-tidy version of the check.

...

Have you run this check over any large code bases to see if it currently catches any true positive diagnostics?

In D87830#2336572, @njames93 wrote:

Probably not quite as verbose but should do the job

// RUN: clang-tidy %s --checks=-*,my-check-to-test --warnings-as-errors=* -- -std=c++11

In D89528#2334795, @martong wrote:

What is the context here? Did it cause any crash/bug or were you just reading through the code for a good night sleep? :D

In D87830#2298198, @aaron.ballman wrote:

Do you have some thoughts about this, should this be pursued, or do you think the use-case is not relevant?

Update commit message

Tidy up commit message

Update commit msg with example

Reformat diagnostic message
Use explicit name longjmp instead of jump function
Fix liberal auto inside Collector

Note that there are no negative test cases that assert that we do NOT report in case a custom or an anonymous namespace is used. For that I would need a small patch in the testing infrastructure.
Patch needed in check_clang_tidy.py:

--- a/clang-tools-extra/test/clang-tidy/check_clang_tidy.py
+++ b/clang-tools-extra/test/clang-tidy/check_clang_tidy.py
@@ -167,7 +167,7 @@ def run_test_once(args, extra_args):
       subprocess.check_output(
           ['FileCheck', '-input-file=' + temp_file_name, input_file_name,
            '-check-prefixes=' + ','.join(check_fixes_prefixes),
-           '-strict-whitespace'],
+           '-strict-whitespace', '--allow-empty'],
           stderr=subprocess.STDOUT)
     except subprocess.CalledProcessError as e:
       print('FileCheck failed:\n' + e.output.decode())
@@ -180,7 +180,7 @@ def run_test_once(args, extra_args):
       subprocess.check_output(
           ['FileCheck', '-input-file=' + messages_file, input_file_name,
            '-check-prefixes=' + ','.join(check_messages_prefixes),
-           '-implicit-check-not={{warning|error}}:'],
+           '-implicit-check-not={{warning|error}}:', '--allow-empty'],
           stderr=subprocess.STDOUT)
     except subprocess.CalledProcessError as e:
       print('FileCheck failed:\n' + e.output.decode())
@@ -195,7 +195,7 @@ def run_test_once(args, extra_args):
       subprocess.check_output(
           ['FileCheck', '-input-file=' + notes_file, input_file_name,
            '-check-prefixes=' + ','.join(check_notes_prefixes),
-           '-implicit-check-not={{note|warning|error}}:'],
+           '-implicit-check-not={{note|warning|error}}:', '--allow-empty'],
           stderr=subprocess.STDOUT)
     except subprocess.CalledProcessError as e:
       print('FileCheck failed:\n' + e.output.decode())

Add abort and terminate handling
Extend tests to cover every exit functions
Extract matcher bind labels

only consider global and ::std scope handlers

CReduce did not manage to produce any meaningful result after a week worth of runtime (more than ~2000 lines of code still remaining after reduction). We could track this down by tracing the ExprEngine code that assigns the Undefined SVal but that seems a huge effort as well. That could be done by debugging the SVal-assigning statements, and setting conditional breakpoints (ie. only break when the value is Undefined). When a breakpoint is hit, we could dump the statement that triggered it and try to reason about the conditions at that point. I also recommend using the rr tool as it allows you to use fixed pointer values while debugging.

Thanks! LGTM now.

Aside from infrastructural questions which I am not qualified ( nor particularly knowledgeable :3 ) to address, this looks good to me.

rename file name in header

I would add one more test for the undefined case. Like a local array variable that is uninitialized. That could mirror some of the null-dereference cases.