Revision tags: llvmorg-21-init, llvmorg-19.1.7 |
|
#
d0d5101f |
| 19-Dec-2024 |
Balazs Benics <benicsbalazs@gmail.com> |
[analyzer][NFC] Migrate nonloc::ConcreteInt to use APSIntPtr (2/4) (#120436)
|
Revision tags: llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3 |
|
#
f3e804b9 |
| 16-Oct-2024 |
Donát Nagy <donat.nagy@ericsson.com> |
[analyzer][clang-tidy][NFC] Clean up eagerly-assume handling (#112209)
This commit is a collection of several very minor code quality
improvements. The main goal is removing the misleading "Bin" su
[analyzer][clang-tidy][NFC] Clean up eagerly-assume handling (#112209)
This commit is a collection of several very minor code quality
improvements. The main goal is removing the misleading "Bin" substring
from the names of several methods and variables (like
`evalEagerlyAssumedBinOpBifurcation`) that are also applied for the
unary logical not operator.
In addition to this, I clarified the doc-comment of the method
`evalEagerlyAssumedBinOpBifurcation` and refactored the body of this
method to fix the capitalization of variable names and replace an
obsolete use of `std::tie` with a structured binding.
Finally, the data member `eagerlyAssumeBinOpBifurcation` of the class
`AnalyzerOptions` was completely removed (including a line in clang-tidy
that sets it to true), because it was never read by any code.
Note that the eagerly-assume mode of the analyzer is controlled by a
different boolean member of `AnalyzerOptions` which is called
`ShouldEagerlyAssume` and is defined via the macro magic from
`AnalyzerOptions.def`.
show more ...
|
Revision tags: llvmorg-19.1.2, llvmorg-19.1.1 |
|
#
752e1037 |
| 19-Sep-2024 |
Kristóf Umann <dkszelethus@gmail.com> |
[analyzer] Explicitly register NoStoreFuncVisitor from alpha.unix.cst… (#108373)
…ring.UninitRead
This is a drastic simplification of #106982. If you read that patch,
this is the same thing with
[analyzer] Explicitly register NoStoreFuncVisitor from alpha.unix.cst… (#108373)
…ring.UninitRead
This is a drastic simplification of #106982. If you read that patch,
this is the same thing with all BugReporterVisitors.cpp and
SValBuilder.cpp changes removed! (since all replies came regarding
changed to those files, I felt the new PR was justified)
The patch was inspired by a pretty poor bug report on FFMpeg:

In this bug report, block is uninitialized, hence the bug report that it
should not have been passed to memcpy. The confusing part is in line 93,
where block was passed as a non-const pointer to seq_unpack_rle_block,
which was obviously meant to initialize block. As developers, we know
that clang likely didn't skip this function and found a path of
execution on which this initialization failed, but NoStoreFuncVisitor
failed to attach the usual "returning without writing to block" message.
I fixed this by instead of tracking the entire array, I tracked the
actual element which was found to be uninitialized (Remember, we
heuristically only check if the first and last-to-access element is
initialized, not the entire array). This is how the bug report looks
now, with 'seq_unpack_rle_block' having notes describing the path of
execution and lack of a value change:


Since NoStoreFuncVisitor was a TU-local class, I moved it back to
BugReporterVisitors.h, and registered it manually in CStringChecker.cpp.
This was done because we don't have a good trackRegionValue() function,
only a trackExpressionValue() function. We have an expression for the
array, but not for its first (or last-to-access) element, so I only had
a MemRegion on hand.
show more ...
|
Revision tags: llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init |
|
#
b3b0d09c |
| 01-Jul-2024 |
Balazs Benics <benicsbalazs@gmail.com> |
Reland "[analyzer][NFC] Reorganize Z3 report refutation" (#97265)
This is exactly as originally landed in #95128,
but now the minimal Z3 version was increased to meet this change in #96682.
http
Reland "[analyzer][NFC] Reorganize Z3 report refutation" (#97265)
This is exactly as originally landed in #95128,
but now the minimal Z3 version was increased to meet this change in #96682.
https://discourse.llvm.org/t/bump-minimal-z3-requirements-from-4-7-1-to-4-8-9/79664/4
---
This change keeps existing behavior, namely that if we hit a Z3 timeout
we will accept the report as "satisfiable".
This prepares for the commit "Harden safeguards for Z3 query times".
https://discourse.llvm.org/t/analyzer-rfc-taming-z3-query-times/79520
(cherry picked from commit 89c26f6c7b0a6dfa257ec090fcf5b6e6e0c89aab)
show more ...
|
#
48ef912e |
| 21-Jun-2024 |
Nikita Popov <npopov@redhat.com> |
[VFS] Avoid <stack> include (NFC)
Directly use a vector instead of wrapping it in a stack, like we do in most places.
|
#
8fc9c03c |
| 18-Jun-2024 |
Balazs Benics <benicsbalazs@gmail.com> |
[analyzer] Revert Z3 changes (#95916)
Requested in:
https://github.com/llvm/llvm-project/pull/95128#issuecomment-2176008007
Revert "[analyzer] Harden safeguards for Z3 query times"
Revert "[ana
[analyzer] Revert Z3 changes (#95916)
Requested in:
https://github.com/llvm/llvm-project/pull/95128#issuecomment-2176008007
Revert "[analyzer] Harden safeguards for Z3 query times"
Revert "[analyzer][NFC] Reorganize Z3 report refutation"
This reverts commit eacc3b3504be061f7334410dd0eb599688ba103a.
This reverts commit 89c26f6c7b0a6dfa257ec090fcf5b6e6e0c89aab.
show more ...
|
#
89c26f6c |
| 18-Jun-2024 |
Balazs Benics <benicsbalazs@gmail.com> |
[analyzer][NFC] Reorganize Z3 report refutation
This change keeps existing behavior, namely that if we hit a Z3 timeout we will accept the report as "satisfiable".
This prepares for the commit "Har
[analyzer][NFC] Reorganize Z3 report refutation
This change keeps existing behavior, namely that if we hit a Z3 timeout we will accept the report as "satisfiable".
This prepares for the commit "Harden safeguards for Z3 query times". https://discourse.llvm.org/t/analyzer-rfc-taming-z3-query-times/79520
Reviewers: NagyDonat, haoNoQ, Xazax-hun, mikhailramalho, Szelethus
Reviewed By: NagyDonat
Pull Request: https://github.com/llvm/llvm-project/pull/95128
show more ...
|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6 |
|
#
efe91cf7 |
| 13-May-2024 |
Rajveer Singh Bharadwaj <rajveer.developer@icloud.com> |
[clang][analyzer] Check for label location bindings in `DereferenceChecker` (#91119)
Resolves #89264
Values should not be stored in addresses of labels, this throws a fatal
error when this happe
[clang][analyzer] Check for label location bindings in `DereferenceChecker` (#91119)
Resolves #89264
Values should not be stored in addresses of labels, this throws a fatal
error when this happens.
---------
Co-authored-by: Balazs Benics <benicsbalazs@gmail.com>
show more ...
|
Revision tags: llvmorg-18.1.5, llvmorg-18.1.4 |
|
#
163301d7 |
| 05-Apr-2024 |
NagyDonat <donat.nagy@ericsson.com> |
[analyzer] Remove barely used class 'KnownSVal' (NFC) (#86953)
The class `KnownSVal` was very magical abstract class within the `SVal`
class hierarchy: with a hacky `classof` method it acted as if
[analyzer] Remove barely used class 'KnownSVal' (NFC) (#86953)
The class `KnownSVal` was very magical abstract class within the `SVal`
class hierarchy: with a hacky `classof` method it acted as if it was the
common ancestor of the classes `UndefinedSVal` and `DefinedSVal`.
However, it was only used in two `getAs<KnownSVal>()` calls and the
signatures of two methods, which does not "pay for" its weird behavior,
so I created this commit that removes it and replaces its use with more
straightforward solutions.
show more ...
|
Revision tags: llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1 |
|
#
ad1b2a81 |
| 06-Mar-2024 |
NagyDonat <donat.nagy@ericsson.com> |
[analyzer] Demonstrate superfluous unsigned >= 0 assumption (#78442)
This commit adds a testcase which highlights the current incorrect
behavior of the CSA diagnostic generation: it produces a note
[analyzer] Demonstrate superfluous unsigned >= 0 assumption (#78442)
This commit adds a testcase which highlights the current incorrect
behavior of the CSA diagnostic generation: it produces a note which says
"Assuming 'arg' is >= 0" in a situation where this is not a fresh
assumption because 'arg' is an unsigned integer.
I also created ticket 78440 to track this bug.
show more ...
|
Revision tags: llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init |
|
#
f3dcc235 |
| 13-Dec-2023 |
Kazu Hirata <kazu@google.com> |
[clang] Use StringRef::{starts,ends}_with (NFC) (#75149)
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}:
[clang] Use StringRef::{starts,ends}_with (NFC) (#75149)
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
show more ...
|
Revision tags: llvmorg-17.0.6, llvmorg-17.0.5 |
|
#
dda8e3de |
| 06-Nov-2023 |
Vlad Serebrennikov <serebrennikov.vladislav@gmail.com> |
[clang][NFC] Refactor `ImplicitParamDecl::ImplicitParamKind`
This patch converts `ImplicitParamDecl::ImplicitParamKind` into a scoped enum at namespace scope, making it eligible for forward declarin
[clang][NFC] Refactor `ImplicitParamDecl::ImplicitParamKind`
This patch converts `ImplicitParamDecl::ImplicitParamKind` into a scoped enum at namespace scope, making it eligible for forward declaring. This is useful for `preferred_type` annotations on bit-fields.
show more ...
|
Revision tags: llvmorg-17.0.4, llvmorg-17.0.3 |
|
#
c68bc172 |
| 16-Oct-2023 |
Gábor Spaits <48805437+spaits@users.noreply.github.com> |
[analyzer] Fix note for member reference (#68691)
In the following code:
```cpp
int main() {
struct Wrapper {char c; int &ref; };
Wrapper w = {.c = 'a', .ref = *(int *)0 };
w.ref =
[analyzer] Fix note for member reference (#68691)
In the following code:
```cpp
int main() {
struct Wrapper {char c; int &ref; };
Wrapper w = {.c = 'a', .ref = *(int *)0 };
w.ref = 1;
}
```
The clang static analyzer will produce the following warnings and notes:
```
test.cpp:12:11: warning: Dereference of null pointer [core.NullDereference]
12 | w.ref = 1;
| ~~~~~~^~~
test.cpp:11:5: note: 'w' initialized here
11 | Wrapper w = {.c = 'a', .ref = *(int *)0 };
| ^~~~~~~~~
test.cpp:12:11: note: Dereference of null pointer
12 | w.ref = 1;
| ~~~~~~^~~
1 warning generated.
```
In the line where `w` is created, the note gives information about the
initialization of `w` instead of `w.ref`. Let's compare it to a similar
case where a null pointer dereference happens to a pointer member:
```cpp
int main() {
struct Wrapper {char c; int *ptr; };
Wrapper w = {.c = 'a', .ptr = nullptr };
*w.ptr = 1;
}
```
Here the following error and notes are seen:
```
test.cpp:18:12: warning: Dereference of null pointer (loaded from field 'ptr') [core.NullDereference]
18 | *w.ptr = 1;
| ~~~ ^
test.cpp:17:5: note: 'w.ptr' initialized to a null pointer value
17 | Wrapper w = {.c = 'a', .ptr = nullptr };
| ^~~~~~~~~
test.cpp:18:12: note: Dereference of null pointer (loaded from field 'ptr')
18 | *w.ptr = 1;
| ~~~ ^
1 warning generated.
```
Here the note that shows the initialization the initialization of
`w.ptr` in shown instead of `w`.
This commit is here to achieve similar notes for member reference as the
notes of member pointers, so the report looks like the following:
```
test.cpp:12:11: warning: Dereference of null pointer [core.NullDereference]
12 | w.ref = 1;
| ~~~~~~^~~
test.cpp:11:5: note: 'w.ref' initialized to a null pointer value
11 | Wrapper w = {.c = 'a', .ref = *(int *)0 };
| ^~~~~~~~~
test.cpp:12:11: note: Dereference of null pointer
12 | w.ref = 1;
| ~~~~~~^~~
1 warning generated.
```
Here the initialization of `w.ref` is shown instead of `w`.
---------
Authored-by: Gábor Spaits <gabor.spaits@ericsson.com>
Reviewed-by: Donát Nagy <donat.nagy@ericsson.com>
show more ...
|
Revision tags: llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2 |
|
#
b16a5932 |
| 29-Sep-2022 |
Endre Fulop <endre.fulop@sigmatechnology.se> |
[analyzer][NFC] Pass the diagnostic message to the TrackConstraintBRVisitor
The `TrackConstraintBRVisitor` should accept a message for the note instead of creating one. It would let us inject domain
[analyzer][NFC] Pass the diagnostic message to the TrackConstraintBRVisitor
The `TrackConstraintBRVisitor` should accept a message for the note instead of creating one. It would let us inject domain-specific knowledge in a non-intrusive way, leading to a more generic visitor.
Differential Revision: https://reviews.llvm.org/D152255
show more ...
|
#
2d861436 |
| 14-Jan-2023 |
Kazu Hirata <kazu@google.com> |
[clang] Remove remaining uses of llvm::Optional (NFC)
This patch removes several "using" declarations and #include "llvm/ADT/Optional.h".
This is part of an effort to migrate from llvm::Optional to
[clang] Remove remaining uses of llvm::Optional (NFC)
This patch removes several "using" declarations and #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 ...
|
#
6ad0788c |
| 14-Jan-2023 |
Kazu Hirata <kazu@google.com> |
[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 ...
|
#
a1580d7b |
| 14-Jan-2023 |
Kazu Hirata <kazu@google.com> |
[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 ...
|
#
b6942a28 |
| 08-Jan-2023 |
Benjamin Kramer <benny.kra@googlemail.com> |
[NFC] Hide implementation details in anonymous namespaces
|
#
53e5cd4d |
| 17-Dec-2022 |
Fangrui Song <i@maskray.me> |
llvm::Optional::value => operator*/operator->
std::optional::value() has undesired exception checking semantics and is unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The
llvm::Optional::value => operator*/operator->
std::optional::value() has undesired exception checking semantics and is unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The call sites block std::optional migration.
This makes `ninja clang` work in the absence of llvm::Optional::value.
show more ...
|
#
21c4dc79 |
| 17-Dec-2022 |
Fangrui Song <i@maskray.me> |
std::optional::value => operator*/operator->
value() has undesired exception checking semantics and calls __throw_bad_optional_access in libc++. Moreover, the API is unavailable without _LIBCPP_NO_E
std::optional::value => operator*/operator->
value() has undesired exception checking semantics and calls __throw_bad_optional_access in libc++. Moreover, the API is unavailable without _LIBCPP_NO_EXCEPTIONS on older Mach-O platforms (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS).
This fixes clang.
show more ...
|
#
b1df3a2c |
| 16-Dec-2022 |
Fangrui Song <i@maskray.me> |
[Support] llvm::Optional => std::optional
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
#
a67a1153 |
| 11-Dec-2022 |
Kazu Hirata <kazu@google.com> |
[StaticAnalyzer] Use std::optional in BugReporterVisitors.cpp (NFC)
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional
[StaticAnalyzer] Use std::optional in BugReporterVisitors.cpp (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
show more ...
|
#
c25cc84b |
| 09-Dec-2022 |
Kazu Hirata <kazu@google.com> |
[clang] Don't including None.h (NFC)
These source files no longer use None, so they do not need to include None.h.
This is part of an effort to migrate from llvm::Optional to std::optional:
https:
[clang] Don't including None.h (NFC)
These source files no longer use None, so they do not need to include None.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 ...
|
#
22731dbd |
| 05-Dec-2022 |
Kazu Hirata <kazu@google.com> |
[clang] Use std::nullopt instead of None in comments (NFC)
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasval
[clang] Use std::nullopt instead of None in comments (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
show more ...
|
#
18060066 |
| 03-Dec-2022 |
Kazu Hirata <kazu@google.com> |
[StaticAnalyzer] Use std::nullopt instead of None (NFC)
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the am
[StaticAnalyzer] Use std::nullopt instead of None (NFC)
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to 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 ...
|