[clang] Don't use Optional::getValue (NFC)

[clang] Don't use Optional::hasValue (NFC)

[NFC][analyzer] Allow CallDescriptions to be matched with CallExprs

Since CallDescriptions can only be matched against CallEvents that are created
during symbolic execution, it was not possible to u

[NFC][analyzer] Allow CallDescriptions to be matched with CallExprs

Since CallDescriptions can only be matched against CallEvents that are created
during symbolic execution, it was not possible to use it in syntactic-only
contexts. For example, even though InnerPointerChecker can check with its set of
CallDescriptions whether a function call is interested during analysis, its
unable to check without hassle whether a non-analyzer piece of code also calls
such a function.

The patch adds the ability to use CallDescriptions in syntactic contexts as
well. While we already have that in Signature, we still want to leverage the
ability to use dynamic information when we have it (function pointers, for
example). This could be done with Signature as well (StdLibraryFunctionsChecker
does it), but it makes it even less of a drop-in replacement.

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

show more ...

[analyzer][NFC] MaybeUInt -> MaybeCount

I forgot to include this in D113594

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

[analyzer][NFC] Use enum for CallDescription flags

Yeah, let's prefer a slightly stronger type representing this.

Reviewed By: martong, xazax.hun

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

[analyzer][NFC] Use enum for CallDescription flags

Yeah, let's prefer a slightly stronger type representing this.

Reviewed By: martong, xazax.hun

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

show more ...

[analyzer][NFC] Consolidate the inner representation of CallDescriptions

`CallDescriptions` have a `RequiredArgs` and `RequiredParams` members,
but they are of different types, `unsigned` and `size_

[analyzer][NFC] Consolidate the inner representation of CallDescriptions

`CallDescriptions` have a `RequiredArgs` and `RequiredParams` members,
but they are of different types, `unsigned` and `size_t` respectively.
In the patch I use only `unsigned` for both, that should be large enough
anyway.
I also introduce the `MaybeUInt` type alias for `Optional<unsigned>`.

Additionally, I also avoid the use of the //smart// less-than operator.

template <typename T>
constexpr bool operator<=(const Optional<T> &X, const T &Y);

Which would check if the optional **has** a value and compare the data
only after. I found it surprising, thus I think we are better off
without it.

Reviewed By: martong, xazax.hun

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

show more ...

[analyzer][NFC] CallDescription should own the qualified name parts

Previously, CallDescription simply referred to the qualified name parts
by `const char*` pointers.
In the future we might want to

[analyzer][NFC] CallDescription should own the qualified name parts

Previously, CallDescription simply referred to the qualified name parts
by `const char*` pointers.
In the future we might want to dynamically load and populate
`CallDescriptionMaps`, hence we will need the `CallDescriptions` to
actually **own** their qualified name parts.

Reviewed By: martong, xazax.hun

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

show more ...

[analyzer][NFC] Introduce CallDescription::matches() in addition to isCalled()

This patch introduces `CallDescription::matches()` member function,
accepting a `CallEvent`.
Semantically, `Call.isCall

[analyzer][NFC] Introduce CallDescription::matches() in addition to isCalled()

This patch introduces `CallDescription::matches()` member function,
accepting a `CallEvent`.
Semantically, `Call.isCalled(CD)` is the same as `CD.matches(Call)`.

The patch also introduces the `matchesAny()` variadic free function template.
It accepts a `CallEvent` and at least one `CallDescription` to match
against.

Reviewed By: martong

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

show more ...

[analyzer][NFC] Introduce CallDescriptionSets

Sometimes we only want to decide if some function is called, and we
don't care which of the set.
This `CallDescriptionSet` will have the same behavior,

[analyzer][NFC] Introduce CallDescriptionSets

Sometimes we only want to decide if some function is called, and we
don't care which of the set.
This `CallDescriptionSet` will have the same behavior, except
instead of `lookup()` returning a pointer to the mapped value,
the `contains()` returns `bool`.
Internally, it uses the `CallDescriptionMap<bool>` for implementing the
behavior. It is preferred, to reuse the generic
`CallDescriptionMap::lookup()` logic, instead of duplicating it.
The generic version might be improved by implementing a hash lookup or
something along those lines.

Reviewed By: martong, Szelethus

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

show more ...

[analyzer][NFC] Separate CallDescription from CallEvent

`CallDescriptions` deserve its own translation unit.
This patch simply moves the corresponding parts.
Also includes the `CallDescription.h` wh

[analyzer][NFC] Separate CallDescription from CallEvent

`CallDescriptions` deserve its own translation unit.
This patch simply moves the corresponding parts.
Also includes the `CallDescription.h` where it's necessary.

Reviewed By: martong, xazax.hun, Szelethus

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

show more ...