Revert "[analyzer] Handle [[assume(cond)]] as __builtin_assume(cond) (#116462)"

This reverts commit 89da344e5879e5347b5057520d5230e40ae24831.

Reason: buildbot breakages e.g., https://lab.llvm.org/b

Revert "[analyzer] Handle [[assume(cond)]] as __builtin_assume(cond) (#116462)"

This reverts commit 89da344e5879e5347b5057520d5230e40ae24831.

Reason: buildbot breakages e.g., https://lab.llvm.org/buildbot/#/builders/55/builds/4556 (for which the reverted patch is the only code change)

show more ...

[analyzer] Handle [[assume(cond)]] as __builtin_assume(cond) (#116462)

Resolves #100762

Gist of the change:
1. All the symbol analysis, constraint manager and expression parsing
logic was alre

[analyzer] Handle [[assume(cond)]] as __builtin_assume(cond) (#116462)

Resolves #100762

Gist of the change:
1. All the symbol analysis, constraint manager and expression parsing
logic was already present, but the previous code didn't "visit" the
expressions within `assume()` by parsing those expressions, all of the
code "just works" by evaluating the SVals, and hence leaning on the same
logic that makes the code with `__builtin_assume` work
2. "Ignore" an expression from adding in CFG if it has side-effects (
similar to CGStmt.cpp (todo add link))
3. Add additional test case for ternary operator handling and modify
CFG.cpp's VisitGuardedExpr code for `continue`-ing if the `ProgramPoint`
is a `StmtPoint`

---------

Co-authored-by: Balazs Benics <benicsbalazs@gmail.com>

show more ...

[HLSL] Implement array temporary support (#79382)

HLSL constant sized array function parameters do not decay to pointers.
Instead constant sized array types are preserved as unique types for
overl

[HLSL] Implement array temporary support (#79382)

HLSL constant sized array function parameters do not decay to pointers.
Instead constant sized array types are preserved as unique types for
overload resolution, template instantiation and name mangling.

This implements the change by adding a new `ArrayParameterType` which
represents a non-decaying `ConstantArrayType`. The new type behaves the
same as `ConstantArrayType` except that it does not decay to a pointer.

Values of `ConstantArrayType` in HLSL decay during overload resolution
via a new `HLSLArrayRValue` cast to `ArrayParameterType`.

`ArrayParamterType` values are passed indirectly by-value to functions
in IR generation resulting in callee generated memcpy instructions.

The behavior of HLSL function calls is documented in the [draft language
specification](https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf)
under the Expr.Post.Call heading.

Additionally the design of this implementation approach is documented in
[Clang's
documentation](https://clang.llvm.org/docs/HLSL/FunctionCalls.html)

Resolves #70123

show more ...

[HLSL] Vector standard conversions (#71098)

HLSL supports vector truncation and element conversions as part of
standard conversion sequences. The vector truncation conversion is a C++
second conve

[HLSL] Vector standard conversions (#71098)

HLSL supports vector truncation and element conversions as part of
standard conversion sequences. The vector truncation conversion is a C++
second conversion in the conversion sequence. If a vector truncation is
in a conversion sequence an element conversion may occur after it before
the standard C++ third conversion.

Vector element conversions can be boolean conversions, floating point or
integral conversions or promotions.

[HLSL Draft
Specification](https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf)

---------

Co-authored-by: Aaron Ballman <aaron@aaronballman.com>

show more ...

Reapply [analyzer] Simplify SVal for simple NonLoc->Loc casts

Reapply after fixing the test by enabling the `debug.ExprInspection` checker.

-----

NonLoc symbolic SVal to Loc casts are not supporte

Reapply [analyzer] Simplify SVal for simple NonLoc->Loc casts

Reapply after fixing the test by enabling the `debug.ExprInspection` checker.

-----

NonLoc symbolic SVal to Loc casts are not supported except for
nonloc::ConcreteInt.

This change simplifies the source SVals so that the more casts can
go through nonloc::ConcreteInt->loc::ConcreteInt path. For example:

void test_simplified_before_cast_add(long long t1) {
long long t2 = t1 + 3;
if (!t2) {
int *p = (int *) t2;
clang_analyzer_eval(p == 0); // expected-warning{{TRUE}}
}
}

If simplified, 't2' is 0, resulting 'p' is nullptr, otherwise 'p'
is unknown.

Fixes #62232

show more ...

Revert "[analyzer] Simplify SVal for simple NonLoc->Loc casts (#66463)"

This reverts commit 3ebf3dd30da219f9f9aee12f42d45d18d55e7580.

I thought "Mergeing" will wait and confirm if the checks pass,

Revert "[analyzer] Simplify SVal for simple NonLoc->Loc casts (#66463)"

This reverts commit 3ebf3dd30da219f9f9aee12f42d45d18d55e7580.

I thought "Mergeing" will wait and confirm if the checks pass, and only
merge it if they succeed. Apparently, it's not the case here xD

The test is just broken in x86. See:
https://lab.llvm.org/buildbot/#/builders/109/builds/73686

show more ...

[analyzer] Simplify SVal for simple NonLoc->Loc casts (#66463)

NonLoc symbolic SVal to Loc casts are not supported except for
nonloc::ConcreteInt.

This change simplifies the source SVals so that

[analyzer] Simplify SVal for simple NonLoc->Loc casts (#66463)

NonLoc symbolic SVal to Loc casts are not supported except for
nonloc::ConcreteInt.

This change simplifies the source SVals so that the more casts can go
through nonloc::ConcreteInt->loc::ConcreteInt path. For example:

```c
void test_simplified_before_cast_add(long long t1) {
long long t2 = t1 + 3;
if (!t2) {
int *p = (int *) t2;
clang_analyzer_eval(p == 0); // expected-warning{{TRUE}}
}
}
```
If simplified, `t2` is 0, resulting `p` is nullptr, otherwise `p` is
unknown.

Fixes #62232

show more ...

[analyzer][NFC] Move away from using raw-for loops inside StaticAnalyzer

I'm involved with the Static Analyzer for the most part.
I think we should embrace newer language standard features and gradu

[analyzer][NFC] Move away from using raw-for loops inside StaticAnalyzer

I'm involved with the Static Analyzer for the most part.
I think we should embrace newer language standard features and gradually
move forward.

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

show more ...

[clang] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is p

[clang] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

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

show more ...

[clang] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Option

[clang] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
std::optional.

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

show more ...

[clang] LLVM_FALLTHROUGH => [[fallthrough]]. NFC

With C++17 there is no Clang pedantic warning or MSVC C5051.

Reviewed By: aaron.ballman

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

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

Depends on D125709

Reviewed By: martong

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

[analyzer][NFC] Inline ExprEngine::evalMinus

Reviewed By: martong

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

[analyzer][NFC] Inline ExprEngine::evalComplement

Reviewed By: martong

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

[analyzer] Refactor makeNull to makeNullWithWidth (NFC)

Usages of makeNull need to be deprecated in favor of makeNullWithWidth
for architectures where the pointer size should not be assumed. This ca

[analyzer] Refactor makeNull to makeNullWithWidth (NFC)

Usages of makeNull need to be deprecated in favor of makeNullWithWidth
for architectures where the pointer size should not be assumed. This can
occur when pointer sizes can be of different sizes, depending on address
space for example. See https://reviews.llvm.org/D118050 as an example.

This was uncovered initially in a downstream compiler project, and
tested through those systems tests.

steakhal performed systems testing across a large set of open source
projects.

Co-authored-by: steakhal
Resolves: https://github.com/llvm/llvm-project/issues/53664

Reviewed By: NoQ, steakhal

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

show more ...

[analyzer] Produce SymbolCast symbols for integral types in SValBuilder::evalCast

Summary: Produce SymbolCast for integral types in `evalCast` function. Apply several simplification techniques while

[analyzer] Produce SymbolCast symbols for integral types in SValBuilder::evalCast

Summary: Produce SymbolCast for integral types in `evalCast` function. Apply several simplification techniques while producing the symbols. Added a boolean option `handle-integral-cast-for-ranges` under `-analyzer-config` flag. Disabled the feature by default.

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

show more ...

[analyzer][NFC] Change return value of StoreManager::attemptDownCast function from SVal to Optional<SVal>

Summary: Refactor return value of `StoreManager::attemptDownCast` function by removing the l

[analyzer][NFC] Change return value of StoreManager::attemptDownCast function from SVal to Optional<SVal>

Summary: Refactor return value of `StoreManager::attemptDownCast` function by removing the last parameter `bool &Failed` and replace the return value `SVal` with `Optional<SVal>`. Make the function consistent with the family of `evalDerivedToBase` by renaming it to `evalBaseToDerived`. Aligned the code on the call side with these changes.

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

show more ...

[clang] Use range-based for loops with llvm::reverse (NFC)

[analyzer][NFC] Refactor llvm::isa<> usages in the StaticAnalyzer

It turns out llvm::isa<> is variadic, and we could have used this at a
lot of places.

The following patterns:
x && isa<T1>(x) ||

[analyzer][NFC] Refactor llvm::isa<> usages in the StaticAnalyzer

It turns out llvm::isa<> is variadic, and we could have used this at a
lot of places.

The following patterns:
x && isa<T1>(x) || isa<T2>(x) ...
Will be replaced by:
isa_and_non_null<T1, T2, ...>(x)

Sometimes it caused further simplifications, when it would cause even
more code smell.

Aside from this, keep in mind that within `assert()` or any macro
functions, we need to wrap the isa<> expression within a parenthesis,
due to the parsing of the comma.

Reviewed By: martong

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

show more ...

[analyzer][NFC] Inline ExprEngine::handleLVectorSplat()

It seems like ExprEngine::handleLVectorSplat() was used at only 2
places. It might be better to directly inline them for readability.

It seem

[analyzer][NFC] Inline ExprEngine::handleLVectorSplat()

It seems like ExprEngine::handleLVectorSplat() was used at only 2
places. It might be better to directly inline them for readability.

It seems like these cases were not covered by tests according to my
coverage measurement, so I'm adding tests as well, demonstrating that no
behavior changed.
Besides that, I'm handling CK_MatrixCast similarly to how the rest of
the unhandled casts are evaluated.

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

Reviewed by: NoQ

show more ...

[analyzer] LValueToRValueBitCasts should evaluate to an r-value

Previously `LValueToRValueBitCast`s were modeled in the same way how
a regular `BitCast` was. However, this should not produce an l-va

[analyzer] LValueToRValueBitCasts should evaluate to an r-value

Previously `LValueToRValueBitCast`s were modeled in the same way how
a regular `BitCast` was. However, this should not produce an l-value.
Modeling bitcasts accurately is tricky, so it's probably better to
model this expression by binding a fresh conjured value.

The following code should not result in a diagnostic:
```lang=C++
__attribute__((always_inline))
static inline constexpr unsigned int_castf32_u32(float __A) {
return __builtin_bit_cast(unsigned int, __A); // no-warning
}
```

Previously, it reported
`Address of stack memory associated with local variable '__A' returned
to caller [core.StackAddressEscape]`.

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

Reviewed by: NoQ, vsavchenko

show more ...

[Matrix] Implement C-style explicit type conversions for matrix types.

This implements C-style type conversions for matrix types, as specified
in clang/docs/MatrixTypes.rst.

Fixes PR47141.

Reviewe

[Matrix] Implement C-style explicit type conversions for matrix types.

This implements C-style type conversions for matrix types, as specified
in clang/docs/MatrixTypes.rst.

Fixes PR47141.

Reviewed By: fhahn

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

show more ...

[analyzer] Fix static_cast on pointer-to-member handling

This commit fixes bug #48739. The bug was caused by the way static_casts
on pointer-to-member caused the CXXBaseSpecifier list of a
MemberToP

[analyzer] Fix static_cast on pointer-to-member handling

This commit fixes bug #48739. The bug was caused by the way static_casts
on pointer-to-member caused the CXXBaseSpecifier list of a
MemberToPointer to grow instead of shrink.
The list is now grown by implicit casts and corresponding entries are
removed by static_casts. No-op static_casts cause no effect.

Reviewed By: vsavchenko

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

show more ...

[Fixed Point] Add fixed-point to floating point cast types and consteval.

Reviewed By: leonardchan

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

[analyzer] Fix crash with pointer to members values

This fix unifies all of the different ways we handled pointer to
members into one. The crash was caused by the fact that the type
of pointer-to-m

[analyzer] Fix crash with pointer to members values

This fix unifies all of the different ways we handled pointer to
members into one. The crash was caused by the fact that the type
of pointer-to-member values was `void *`, and while this works
for the vast majority of cases it breaks when we actually need
to explain the path for the report.

rdar://problem/64202361

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

show more ...