[clang] Fixed issue #128882: don't warn if 1st argument to 'getcwd' is NULL (PR #135720)

[Balazs Benics via cfe-commits]

================
@@ -105,9 +105,6 @@ void errno_getcwd(char *Buf, size_t Sz) {
     clang_analyzer_eval(errno != 0);   // expected-warning{{TRUE}}
     clang_analyzer_eval(Path == NULL); // expected-warning{{TRUE}}
     if (errno) {}                      // no warning
-  } else if (Path == NULL) {
-    clang_analyzer_eval(errno != 0);   // expected-warning{{TRUE}}
-    if (errno) {}                      // no warning
----------------
steakhal wrote:

How to interpret this:
So after your patch, now we reach the print statement at line 109 with 2 paths, one in which `errno` is known to be zero, and also a different path where we know it's not zero. This is why the `true` expectation is met, but complains about that it also prints `false` for the same line. I know it's hard to wrap your head around.

Let's step back. What does this test? We are in a branch when `Path` aka. the result of `getcwd` is NULL, aka. we had an error. In this case `errno` should indicate the specific error that happened, which means we should know here that `errno` is not zero. This is exactly what is enforced by the line 109.

What if on the success path `Path` is equal to `Buf`, which is a top-level symbol, thus when compared `Path` against `NULL`, we will have a state-split, so we enter this `Path == NULL` branch even on the success path. This is why `errno` is known there to be non-zero, hence the new diagnostic.

What is missing I think is a new ` ReturnValueCondition` for the success path constraining the return value NOT being null. @balazske WDYT of this reasoning?
Can we have multiple `ReturnValueCondition`s for a summary? I have something like `ReturnValueCondition(BO_NE, SingleValue(0))` in mind to add there.

https://github.com/llvm/llvm-project/pull/135720