Adds a clang-tidy check for the incorrect use of `empty()` on a
container when the result of the call is ignored.

Authored-by: Abraham Corea Diaz <abrahamcd@google.com>
Co-authored-by: Denis Nikitin <denik@google.com>

Reviewed By: cjdb

Differential Revision: https://reviews.llvm.org/D128372

(cherry picked from commit ec3f8fe)

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
(cherry picked from commit 9ddc8af)

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
(cherry picked from commit 6c8b8a6)

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
(cherry picked from commit 02c905c)

…(NFC)

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
(cherry picked from commit b5716de)

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
(cherry picked from commit b5fdd53)

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
(cherry picked from commit 628556b)

std::optional<T> does not have an equivalent method.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
(cherry picked from commit 1cb7fba)

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
(cherry picked from commit c824db4)

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
(cherry picked from commit ec94a5b)

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
(cherry picked from commit 602af71)

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
(cherry picked from commit a67a115)

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
(cherry picked from commit eacf7c8)

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
(cherry picked from commit 3e57273)

getAPSIntType crashes when analzying a simple case that uses a fixed
point type. getAPSIntType needs to handle fixed point types differently
to get sign information. LIT and Unittests were added since there were
 none previously added.

   clang: <root>/clang/include/clang/StaticAnalyzer/Core/PathSensitive/BasicValueFactory.h:155:
      clang::ento::APSIntType clang::ento::BasicValueFactory::getAPSIntType(clang::QualType) const:
      Assertion `T->isIntegralOrEnumerationType() || Loc::isLocType(T)' failed.

    Program received signal SIGABRT, Aborted.
    0x00007ffff66e2387 in raise () from /lib64/libc.so.6
    (gdb) bt
        at <root>/clang/include/clang/StaticAnalyzer/Core/PathSensitive/BasicValueFactory.h:155
        at <root>/clang/include/clang/StaticAnalyzer/Core/PathSensitive/BasicValueFactory.h:172
          LHS=0x108965a0, op=clang::BO_Shr, RHS=..., resultTy=...) at
          <root>/clang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:213
          (this=0x1088e460, state=..., op=clang::BO_Shr, lhs=..., rhs=..., resultTy=...)
          at <root>/clang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:681

Reviewed By: steakhal

Differential Revision: https://reviews.llvm.org/D139759

(cherry picked from commit 443b46e)

…pace

No need for the templated function "processMatch", since
we can infer the type with llvm:isa.

(cherry picked from commit d3c3de6)

…space only

- Do not analyze header files, since we don't want to promote
  using anonymous namespaces there.

- Do not warn about const/constexpr variables, those are implicitly
  static in C++ and they don't need to be moved to an anonymous
  namespace. Warning about redundant static in general could be
  implemented as a standalone check, moving away some of the
  functionality from this check.

This check has been introduced in the current release, thus
no mention of this change is needed in the Release Notes.

Differential Revision: https://reviews.llvm.org/D139113

(cherry picked from commit 35d9f87)

…properties.

The NullabilityChecker has a very early policy decision that non-inlined
property accesses will be inferred as returning nonnull, despite nullability
annotations to the contrary. This decision eliminates false positives related
to very common code patterns that look like this:

if (foo.prop) {
    [bar doStuffWithNonnull:foo.prop];
}

While this probably represents a correct nil-check, the analyzer can't
determine correctness without gaining visibility into the property
implementation.

Unfortunately, inferring nullable properties as nonnull comes at the cost of
significantly reduced code coverage. My goal here is to enable detection of
many property-related nullability violations without a large increase
in false positives.

The approach is to introduce a heuristic: after accessing the value of
a property, if the analyzer at any time proves that the property value is
nonnull (which would happen in particular due to a nil-check conditional),
then subsequent property accesses on that code path will be *inferred*
as nonnull. This captures the pattern described above, which I believe
to be the dominant source of false positives in real code.

https://reviews.llvm.org/D131655
(cherry picked from commit 6ab01d4)

…ed lattice element

Previously, the diagnoser could only receive the Environment at a given program point. Now, it receives the complete dataflow state: the environment and lattice element.

This change does not contain any tests because we modify the checkDataflow function to rely on the newly introduced lattice element in PostVisitCFG, and existing tests that verify lattice elements depend on this overload of checkDataflow.

Reviewed By: gribozavr2, ymandel

Differential Revision: https://reviews.llvm.org/D139868

(cherry picked from commit 82d50fe)

…tionsChecker.

The checker applies constraints in a sequence and adds new nodes for these states.
If a constraint violation is found this sequence should be stopped with a sink
(error) node. Instead the `generateErrorNode` did add a new error node as a new
branch that is parallel to the other node sequence, the other branch was not
stopped and analysis was continuing on that invalid branch.
To add an error node after any previous node a new version of `generateErrorNode`
is needed, this function is added here and used by `StdLibraryFunctionsChecker`.
The added test executes a situation where the checker adds a number of
constraints before it finds a constraint violation.

Reviewed By: NoQ

Differential Revision: https://reviews.llvm.org/D137722

(cherry picked from commit da06606)