[analyzer][NFC] Migrate nonloc::ConcreteInt to use APSIntPtr (2/4) (#120436)

[analyzer][NFC] Take SVal and NonLoc by value

Migrate {starts,ends}with_insensitive to {starts,ends}_with_insensitive (NFC)

This patch migrates uses of StringRef::{starts,ends}with_insensitive
to StringRef::{starts,ends}_with_insensitive so tha

Migrate {starts,ends}with_insensitive to {starts,ends}_with_insensitive (NFC)

This patch migrates uses of StringRef::{starts,ends}with_insensitive
to StringRef::{starts,ends}_with_insensitive so that we can use names
similar to those used in std::string_view.

Note that the llvm/ directory has migrated in commit
6c3ea866e93003e16fc55d3b5cedd3bc371d1fde.

I'll post a separate patch to deprecate
StringRef::{starts,ends}with_insensitive.

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

show more ...

[analyzer][NFC] Prefer using isa<> instead getAs<> in conditions

Depends on D125709

Reviewed By: martong

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

[clang] Rename StringRef _lower() method calls to _insensitive()

This is mostly a mechanical change, but a testcase that contains
parts of the StringRef class (clang/test/Analysis/llvm-conventions.c

[clang] Rename StringRef _lower() method calls to _insensitive()

This is mostly a mechanical change, but a testcase that contains
parts of the StringRef class (clang/test/Analysis/llvm-conventions.cpp)
isn't touched.

show more ...

[Analyzer] Handle pointer implemented as iterators in iterator checkers

Iterators are an abstraction of pointers and in some data structures
iterators may be implemented by pointers. This patch adds

[Analyzer] Handle pointer implemented as iterators in iterator checkers

Iterators are an abstraction of pointers and in some data structures
iterators may be implemented by pointers. This patch adds support for
iterators implemented as pointers in all the iterator checkers
(including iterator modeling).

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

show more ...

[Analyzer] Fix for iterator modeling and checkers: handle negative numbers correctly

Currently, using negative numbers in iterator operations (additions and
subractions) results in advancements with

[Analyzer] Fix for iterator modeling and checkers: handle negative numbers correctly

Currently, using negative numbers in iterator operations (additions and
subractions) results in advancements with huge positive numbers due to
an error. This patch fixes it.

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

show more ...

[Analyzer] Model STL Algoirthms to improve the iterator checkers

STL Algorithms are usually implemented in a tricky for performance
reasons which is too complicated for the analyzer. Furthermore inl

[Analyzer] Model STL Algoirthms to improve the iterator checkers

STL Algorithms are usually implemented in a tricky for performance
reasons which is too complicated for the analyzer. Furthermore inlining
them is costly. Instead of inlining we should model their behavior
according to the specifications.

This patch is the first step towards STL Algorithm modeling. It models
all the `find()`-like functions in a simple way: the result is either
found or not. In the future it can be extended to only return success if
container modeling is also extended in a way the it keeps track of
trivial insertions and deletions.

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

show more ...

[Analyzer] Split container modeling from iterator modeling

Iterator modeling depends on container modeling,
but not vice versa. This enables the possibility
to arrange these two modeling checkers in

[Analyzer] Split container modeling from iterator modeling

Iterator modeling depends on container modeling,
but not vice versa. This enables the possibility
to arrange these two modeling checkers into
separate layers.

There are several advantages for doing this: the
first one is that this way we can keep the
respective modeling checkers moderately simple
and small. Furthermore, this enables creation of
checkers on container operations which only
depend on the container modeling. Thus iterator
modeling can be disabled together with the
iterator checkers if they are not needed.

Since many container operations also affect
iterators, container modeling also uses the
iterator library: it creates iterator positions
upon calling the `begin()` or `end()` method of
a containter (but propagation of the abstract
position is left to the iterator modeling),
shifts or invalidates iterators according to the
rules upon calling a container modifier and
rebinds the iterator to a new container upon
`std::move()`.

Iterator modeling propagates the abstract
iterator position, handles the relations between
iterator positions and models iterator
operations such as increments and decrements.

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

show more ...

[Analyzer][NFC] Iterator Checkers - Separate iterator modeling and the actual checkers

A monolithic checker class is hard to maintain. This patch splits it up
into a modeling part, the three checker

[Analyzer][NFC] Iterator Checkers - Separate iterator modeling and the actual checkers

A monolithic checker class is hard to maintain. This patch splits it up
into a modeling part, the three checkers and a debug checker. The common
functions are moved into a library.

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

show more ...