Certain Fuchsia functions may return handles that are not owned by the
current closure. This adds a check in order to determine when these
handles are released.
Differential Revision: https://reviews.llvm.org/D93868
When we annotating a function header so that it could be used by other
TU, we also need to make sure the function is parsed correctly within
the same TU. So if we can find the function's implementation,
ignore the annotations, otherwise, false positive would occur.
Move the escape by value case to post call and do not escape the handle
if the function is inlined and we have analyzed the handle.
Differential Revision: https://reviews.llvm.org/D91902
The fd parameter of
```
void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset)
```
should be constrained to the range [0, IntMax] as that is of type int.
Constraining to the range [0, Off_tMax] would result in a crash as that is
of a signed type with the value of 0xff..f (-1).
The crash would happen when we try to apply the arg constraints.
At line 583: assert(Min <= Max), as 0 <= -1 is not satisfied
The mmap64 is fixed for the same reason.
Reviewed By: martong, vsavchenko
Differential Revision: https://reviews.llvm.org/D92307
Support adding handle annotations to sturucture that contains
handles. All the handles referenced by the structure (direct
value or ptr) would be treated as containing the
release/use/acquire annotations directly.
Patch by Yu Shan
Differential Revision: https://reviews.llvm.org/D91223
e00629f777 "[scan-build] Fix clang++ pathname" had
removed the -MAJOR.MINOR suffix, but since presumably LLVM 7 the suffix is only
-MAJOR, so ClangCXX (i.e., the CLANG_CXX environment variable passed to
clang/tools/scan-build/libexec/ccc-analyzer) now contained a non-existing
/path/to/clang-12++ (which apparently went largely unnoticed as
clang/tools/scan-build/libexec/ccc-analyzer falls back to just 'clang++' if the
executable denoted by CLANG_CXX does not exist).
For the new clang/test/Analysis/scan-build/cxx-name.test to be effective,
%scan-build must now take care to pass the clang executable's resolved pathname
(i.e., ending in .../clang-MAJOR rather than just .../clang) to --use-analyzer.
Differential Revision: https://reviews.llvm.org/D89481
It is no longer needed to add summaries of 'getline' for different
possible underlying types of ssize_t. We can just simply lookup the
type.
Differential Revision: https://reviews.llvm.org/D88092
The summary and very short discussion in D82122 summarizes whats happening here.
In short, liveness talks about variables, or expressions, anything that
has a value. Well, statements just simply don't have a one.
Differential Revision: https://reviews.llvm.org/D82598
Add the BufferSize argument constraint to fread and fwrite. This change
itself makes it possible to discover a security critical case, described
in SEI-CERT ARR38-C.
We also add the not-null constraint on the 3rd arguments.
In this patch, I also remove those lambdas that don't take any
parameters (Fwrite, Fread, Getc), thus making the code better
structured.
Differential Revision: https://reviews.llvm.org/D87081
Previously, it was a tedious task to comprehend Z3 dumps.
We will use the same name prefix just as we use in the corresponding dump method
For all `SymbolData` values:
`$###` -> `conj_$###`
`$###` -> `derived_$###`
`$###` -> `extent_$###`
`$###` -> `meta_$###`
`$###` -> `reg_$###`
Reviewed By: xazax.hun,mikhail.ramalho
Differential Revision: https://reviews.llvm.org/D86223
We did not evaluate such expressions, just returned `Unknown` for such cases.
After this patch, we will be able to access a unique value identifying a template instantiation via the value of the `PRETTY_FUNCTION` predefined expression.
Reviewed By: vsavchenko
Differential Revision: https://reviews.llvm.org/D87004
Based on the discussion in D82598#2171312. Thanks @NoQ!
D82598 is titled "Get rid of statement liveness, because such a thing doesn't
exist", and indeed, expressions express a value, non-expression statements
don't.
if (a && get() || []{ return true; }())
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ has a value
~ has a value
~~~~~~~~~~ has a value
~~~~~~~~~~~~~~~~~~~~ has a value
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ doesn't have a value
That is simple enough, so it would only make sense if we only assigned symbolic
values to expressions in the static analyzer. Yet the interface checkers can
access presents, among other strange things, the following two methods:
ProgramState::BindExpr(const Stmt *S, const LocationContext *LCtx, SVal V,
bool Invalidate=true)
ProgramState::getSVal(const Stmt *S, const LocationContext *LCtx)
So, what gives? Turns out, we make an exception for ReturnStmt (which we'll
leave for another time) and ObjCForCollectionStmt. For any other loops, in order
to know whether we should analyze another iteration, among other things, we
evaluate it's condition. Which is a problem for ObjCForCollectionStmt, because
it simply doesn't have one (CXXForRangeStmt has an implicit one!). In its
absence, we assigned the actual statement with a concrete 1 or 0 to indicate
whether there are any more iterations left. However, this is wildly incorrect,
its just simply not true that the for statement has a value of 1 or 0, we can't
calculate its liveness because that doesn't make any sense either, so this patch
turns it into a GDM trait.
Fixing this allows us to reinstate the assert removed in
https://reviews.llvm.org/rG032b78a0762bee129f33e4255ada6d374aa70c71.
Differential Revision: https://reviews.llvm.org/D86736
In short, macro expansions handled the case where a variadic parameter mapped to
multiple arguments, but not the other way around. An internal ticket was
submitted that demonstrated that we fail an assertion. Macro expansion so far
worked by lexing the source code token-by-token and using the Preprocessor to
turn these tokens into identifiers or just get their proper spelling, but what
this counter intuitively doesn't do, is actually expand these macros, so we have
to do the heavy lifting -- in this case, figure out what __VA_ARGS__ expands
into. Since this case can only occur in a nested macro, the information we
gathered from the containing macro does contain this information. If a parameter
resolves to __VA_ARGS__, we need to temporarily stop getting our tokens from the
lexer, and get the tokens from what __VA_ARGS__ maps to.
Differential Revision: https://reviews.llvm.org/D86135
There are 2 reasons to remove strcasecmp and strncasecmp.
1) They are also modeled in CStringChecker and the related argumentum
contraints are checked there.
2) The argument constraints are checked in CStringChecker::evalCall.
This is fundamentally flawed, they should be checked in checkPreCall.
Even if we set up CStringChecker as a weak dependency for
StdLibraryFunctionsChecker then the latter reports the warning always.
Besides, CStringChecker fails to discover the constraint violation
before the call, so, its evalCall returns with `true` and then
StdCLibraryFunctions also tries to evaluate, this causes an assertion
in CheckerManager.
Either we fix CStringChecker to handle the call prerequisites in
checkPreCall, or we must not evaluate any pure functions in
StdCLibraryFunctions that are also handled in CStringChecker.
We do the latter in this patch.
Differential Revision: https://reviews.llvm.org/D87239
We want the generice StdLibraryFunctionsChecker to report only if there
are no specific checkers that would handle the argument constraint for a
function.
Note, the assumptions are still evaluated, even if the arguement
constraint checker is set to not report. This means that the assumptions
made in the generic StdLibraryFunctionsChecker should be an
over-approximation of the assumptions made in the specific checkers. But
most importantly, the assumptions should not contradict.
Differential Revision: https://reviews.llvm.org/D87240
The "restrict" keyword is illegal in C++, however, many libc
implementations use the "__restrict" compiler intrinsic in functions
prototypes. The "__restrict" keyword qualifies a type as a restricted type
even in C++.
In case of any non-C99 languages, we don't want to match based on the
restrict qualifier because we cannot know if the given libc implementation
qualifies the paramter type or not.
Differential Revision: https://reviews.llvm.org/D87097
By using optionals, we no longer have to check the validity of types that we
get from a lookup. This way, the definition of the summaries have a declarative
form, there are no superflous conditions in the source code.
Differential Revision: https://reviews.llvm.org/D86531
llvm::isa<>() and llvm::isa_and_not_null<>() template functions recently became
variadic. Unfortunately this causes crashes in case of isa_and_not_null<>()
and incorrect behavior in isa<>(). This patch fixes this issue.
Differential Revision: https://reviews.llvm.org/D85728
The successfulness of a dynamic cast depends only on the C++ class, not the pointer or reference. Thus if *A is a *B, then &A is a &B,
const *A is a const *B etc. This patch changes DynamicCastInfo to store
and check the cast between the unqualified pointed/referenced types.
It also removes e.g. SubstTemplateTypeParmType from both the pointer
and the pointed type.
Differential Revision: https://reviews.llvm.org/D85752
Summary:
Make exactly single NodeBuilder exists at any given time
Reviewers: NoQ, Szelethus, vsavchenko, xazax.hun
Reviewed By: NoQ
Subscribers: martong, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D85796
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
Report undefined pointer dereference in similar way as null pointer dereference.
Reviewed By: NoQ
Differential Revision: https://reviews.llvm.org/D84520
Summary:
In case a pointer iterator is incremented in a binary plus expression
(operator+), where the iterator is on the RHS, IteratorModeling should
now detect, and track the resulting value.
Reviewers: Szelethus, baloghadamsoftware
Reviewed By: baloghadamsoftware
Subscribers: rnkovacs, whisperity, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, Charusso, steakhal, martong, ASDenysPetrov, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D83190
The uniqueing decl in PathDiagnostic is the declaration with the
uniqueing loc, as stated by documentation comments.
It is enough to include the uniqueing loc in the profile. It is possible
to have objects with different uniqueing decl but same location, at
least with templates. These belong to the same class and should have
same profile.
Reviewed By: vsavchenko, NoQ
Differential Revision: https://reviews.llvm.org/D84843
We found a case where Typedef Name Declarations were not being added
correctly when importing builtin types. This exposed the need for a
TypedefNameDecl visitor so these types can be added by RecordDecl and
fields.
This code is covered by the ASTImporterTest cases that use the implicit
struct __NSConstantString_tag definitions.
Thanks to @martong for the debugging assist!
Depends on D83970.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D83992
Was accidentally squished into
rGb6cbe6cb0399d4671e5384dcc326af56bc6bd122. The assert fires on the code
snippet included in this commit.
More discussion can be found in https://reviews.llvm.org/D82598.
Summary:
Use the built-in functionality BugType::SuppressOnSink
instead of a manual solution in StreamChecker.
Differential Revision: https://reviews.llvm.org/D83120
Summary:
This commmit adds another relation that we can track separately from
range constraints. Symbol disequality can help us understand that
two equivalence classes are not equal to each other. We can generalize
this knowledge to classes because for every a,b,c, and d that
a == b, c == d, and b != c it is true that a != d.
As a result, we can reason about other equalities/disequalities of symbols
that we know nothing else about, i.e. no constraint ranges associated
with them. However, we also benefit from the knowledge of disequal
symbols by following the rule:
if a != b and b == C where C is a constant, a != C
This information can refine associated ranges for different classes
and reduce the number of false positives and paths to explore.
Differential Revision: https://reviews.llvm.org/D83286
Summary:
For the most cases, we try to reason about symbol either based on the
information we know about that symbol in particular or about its
composite parts. This is faster and eliminates costly brute force
searches through existing constraints.
However, we do want to support some cases that are widespread enough
and involve reasoning about different existing constraints at once.
These include:
* resoning about 'a - b' based on what we know about 'b - a'
* reasoning about 'a <= b' based on what we know about 'a > b' or 'a < b'
This commit expands on that part by tracking symbols known to be equal
while still avoiding brute force searches. It changes the way we track
constraints for individual symbols. If we know for a fact that 'a == b'
then there is no need in tracking constraints for both 'a' and 'b' especially
if these constraints are different. This additional relationship makes
dead/live logic for constraints harder as we want to maintain as much
information on the equivalence class as possible, but we still won't
carry the information that we don't need anymore.
Differential Revision: https://reviews.llvm.org/D82445
Summary:
Adding networking functions from the POSIX standard (2017). This includes
functions that deal with sockets from socket.h, netdb.h.
In 'socket.h' of some libc implementations (e.g. glibc) with C99, sockaddr
parameter is a transparent union of the underlying sockaddr_ family of pointers
instead of being a pointer to struct sockaddr. In these cases, the standardized
signature will not match, thus we try to match with another signature that has
the joker Irrelevant type. In the case of transparent unions, we also not add
those constraints which require pointer types for the sockaddr param.
Interestingly, in 'netdb.h' sockaddr is not handled as a transparent union.
Tags: #clang
Differential Revision: https://reviews.llvm.org/D83407
Summary:
Random access iterators must handle operator+, where the iterator is on the
RHS. The system header simulator library is extended with these operators.
Reviewers: Szelethus
Subscribers: whisperity, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, Charusso, steakhal, martong, ASDenysPetrov, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D83226
The patch that introduces handling iterators implemented as pointers may
cause crash in some projects because pointer difference is mistakenly
handled as pointer decrement. (Similair case for iterators implemented
as class instances are already handled correctly.) This patch fixes this
issue.
The second case that causes crash is comparison of an iterator
implemented as pointer and a null-pointer. This patch contains a fix for
this issue as well.
The third case which causes crash is that the checker mistakenly
considers all integers as nonloc::ConcreteInt when handling an increment
or decrement of an iterator implemented as pointers. This patch adds a
fix for this too.
The last case where crashes were detected is when checking for success
of an std::advance() operation. Since the modeling of iterators
implemented as pointers is still incomplete this may result in an
assertion. This patch replaces the assertion with an early exit and
adds a FIXME there.
Differential Revision: https://reviews.llvm.org/D83295
Summary:
Two CSA bug reports where only the uniqueing location is different
should be treated as different problems. The role of uniqueing location
is to differentiate bug reports.
Reviewers: Szelethus, baloghadamsoftware, NoQ, vsavchenko, xazax.hun, martong
Reviewed By: NoQ
Subscribers: NoQ, rnkovacs, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, gamesh411, Charusso, martong, ASDenysPetrov, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D83115
Summary:
The default CTUImportThreshold (8) seems to be too conservative with C projects.
We increase this value to 24 and we introduce another threshold for C++ source
files (defaulted to 8) because their AST is way more compilcated than C source
files.
Differential Revision: https://reviews.llvm.org/D83475
* The getLine and getColumn functions need to update the position, or
they will return stale data for buffered streams. This fixes a bug in
the clang -analyzer-checker-option-help option, which was not wrapping
the help text correctly when stdout is not a TTY.
* If the stream contains multi-byte UTF-8 sequences, then the whole
sequence needs to be considered to be a single character. This has the
edge case that the buffer might fill up and be flushed part way
through a character.
* If the stream contains East Asian wide characters, these will be
rendered twice as wide as other characters, so we need to increase the
column count to match.
This doesn't attempt to handle everything unicode can do (combining
characters, right-to-left markers, ...), but hopefully covers most
things likely to be common in messages and source code we might want to
print.
Differential revision: https://reviews.llvm.org/D76291
Hidden checkers (those marked with Hidden in Checkers.td) are meant for
development purposes only, and are only displayed under
-analyzer-checker-help-developer, so users shouldn't see reports from them.
I moved StdLibraryFunctionsArg checker to the unix package from apiModeling as
it violated this rule. I believe this change doesn't deserve a different
revision because it is in alpha, and the name is so bad anyways I don't
immediately care where it is, because we'll have to revisit it soon enough.
Differential Revision: https://reviews.llvm.org/D81750
Adding file handling functions from the POSIX standard (2017).
A new checker option is introduced to enable them.
In follow-up patches I am going to upstream networking, pthread, and other
groups of POSIX functions.
Differential Revision: https://reviews.llvm.org/D82288
Summary:
The default value of 100 makes the analysis slow. Projects of considerable
size can take more time to finish than it is practical. The new default
setting of 8 is based on the analysis of LLVM itself. With the old default
value of 100 the analysis time was over a magnitude slower. Thresholding the
load of ASTUnits is to be extended in the future with a more fine-tuneable
solution that accomodates to the specifics of the project analyzed.
Reviewers: martong, balazske, Szelethus
Subscribers: whisperity, xazax.hun, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, Charusso, steakhal, ASDenysPetrov, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D82561
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
There is major a bug found in iterator modeling: upon adding a value
to or subtracting a value from an iterator the position of the original
iterator is also changed beside the result. This patch fixes this bug.
To catch such bugs in the future we also changed the tests to look for
regular expressions including an end-of-line symbol (`$`) so we can
prevent false matches where only the tested prefix matches.
Another minor bug is that when printing the state, all the iterator
positions are printed in a single line. This patch also fixes this.
Differential Revision: https://reviews.llvm.org/D82385
Pass EvalCallOptions via runCheckersForEvalCall into defaultEvalCall.
Update the AnalysisOrderChecker to support evalCall for testing.
Differential Revision: https://reviews.llvm.org/D82256
Summary:
This patch addresses https://bugs.llvm.org/show_bug.cgi?id=46256
The spec of coroutine requires that the expression co_await promise.final_suspend() shall not be potentially-throwing.
To check this, we recursively look at every call (including Call, MemberCall, OperatorCall and Constructor) in all code
generated by the final suspend, and ensure that the callees are declared with noexcept. We also look at any returned data
type that requires explicit destruction, and check their destructors for noexcept.
This patch does not check declarations with dependent types yet, which will be done in future patches.
Updated all tests to add noexcept to the required functions, and added a dedicated test for this patch.
This patch might start to cause existing codebase fail to compile because most people may not have been strict in tagging
all the related functions noexcept.
Reviewers: lewissbaker, modocache, junparser
Reviewed By: modocache
Subscribers: arphaman, junparser, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D82029
Summary:
Windows forbidden file path characters are used in a field `file`, while creating a dump `dot` file using an argument -analyzer-dump-egraph. It specifically relates to angle brackets when using `<scratch space>`, `<built-in>`, `<command line>` values in filenames. It causes that script exploded-graph-rewriter.py incorrectly parses the dump.
Fix:
Remove forbidden characters from filename for Windows platform, when creating graph dump file.
Differential Revision: https://reviews.llvm.org/D82103
Summary:
Handle `\l` separately because a string literal can be in code like "string\\literal" with the `\l` inside. Also on Windows macros __FILE__ produces specific delimiters `\` and a directory or file may starts with the letter `l`.
Fix:
Use regex for replacing all `\l` (like `,\l`, `}\l`, `[\l`) except `\\l`, because a literal as a rule contains multiple `\` before `\l`.
Differential Revision: https://reviews.llvm.org/D82092
Summary:
Bug reports of resource leak are now improved.
If there are multiple resource leak paths for the same stream,
only one wil be reported.
Reviewers: Szelethus, xazax.hun, baloghadamsoftware, NoQ
Reviewed By: Szelethus, NoQ
Subscribers: NoQ, rnkovacs, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, gamesh411, Charusso, martong, ASDenysPetrov, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D81407
https://bugs.llvm.org/show_bug.cgi?id=46253
This is an obvious hack because realloc isn't any more affected than other
functions modeled by MallocChecker (or any user of CallDescription really),
but the nice solution will take some time to implement.
Differential Revision: https://reviews.llvm.org/D81745
Summary:
EOF macro token coming from a PCH file on macOS while marked as literal,
doesn't contain any literal data. This causes crash on every project
using PCHs.
This commit doesn't resolve the problem with PCH (maybe it was
designed like this for a purpose) or with `tryExpandAsInteger`, but
rather simply shoots off a crash itself.
Differential Revision: https://reviews.llvm.org/D81916
Summary:
Implemented RangeConstraintManager::getRangeForComparisonSymbol which handles comparison operators.
RangeConstraintManager::getRangeForComparisonSymbol cares about the sanity of comparison expressions sequences helps reasonably to branch an exploded graph.
It can significantly reduce the graph and speed up the analysis. For more details, please, see the differential revision.
This fixes https://bugs.llvm.org/show_bug.cgi?id=13426
Differential Revision: https://reviews.llvm.org/D78933
Summary:
After an escaped FILE* stream handle it is not possible to make
reliable checks on it because any function call can have effect
on it.
Reviewers: Szelethus, baloghadamsoftware, martong, NoQ
Reviewed By: NoQ
Subscribers: NoQ, rnkovacs, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, gamesh411, Charusso, martong, ASDenysPetrov, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80699
Checker dependencies were added D54438 to solve a bug where the checker names
were incorrectly registered, for example, InnerPointerChecker would incorrectly
emit diagnostics under the name MallocChecker, or vice versa [1]. Since the
system over the course of about a year matured, our expectations of what a role
of a dependency and a dependent checker should be crystallized a bit more --
D77474 and its summary, as well as a variety of patches in the stack
demonstrates how we try to keep dependencies to play a purely modeling role. In
fact, D78126 outright forbids diagnostics under a dependency checkers name.
These dependencies ensured the registration order and enabling only when all
dependencies are satisfied. This was a very "strong" contract however, that
doesn't fit the dependency added in D79420. As its summary suggests, this
relation is directly in between diagnostics, not modeling -- we'd prefer a more
specific warning over a general one.
To support this, I added a new dependency kind, weak dependencies. These are not
as strict of a contract, they only express a preference in registration order.
If a weak dependency isn't satisfied, the checker may still be enabled, but if
it is, checker registration, and transitively, checker callback evaluation order
is ensured.
If you are not familiar with the TableGen changes, a rather short description
can be found in the summary of D75360. A lengthier one is in D58065.
[1] https://www.youtube.com/watch?v=eqKeqHRAhQM
Differential Revision: https://reviews.llvm.org/D80905
Retrieving the parameter location of functions was disabled because it
may causes crashes due to the fact that functions may have multiple
declarations and without definition it is difficult to ensure that
always the same declration is used. Now parameters are stored in
`ParamRegions` which are independent of the declaration of the function,
therefore the same parameters always have the same regions,
independently of the function declaration used actually. This allows us
to remove the limitation described above.
Differential Revision: https://reviews.llvm.org/D80286
Currently, parameters of functions without their definition present cannot
be represented as regions because it would be difficult to ensure that the
same declaration is used in every case. To overcome this, we split
`VarRegion` to two subclasses: `NonParamVarRegion` and `ParamVarRegion`.
The latter does not store the `Decl` of the parameter variable. Instead it
stores the index of the parameter which enables retrieving the actual
`Decl` every time using the function declaration of the stack frame. To
achieve this we also removed storing of `Decl` from `DeclRegion` and made
`getDecl()` pure virtual. The individual `Decl`s are stored in the
appropriate subclasses, such as `FieldRegion`, `ObjCIvarRegion` and the
newly introduced `NonParamVarRegion`.
Differential Revision: https://reviews.llvm.org/D80522
Summary: LoopWidening is invalidating references coming from type
aliases which lead to a crash.
Patch by Abbas Sabra!
Differential Revision: https://reviews.llvm.org/D80669
Summary:
See https://bugs.llvm.org/show_bug.cgi?id=46128. The checker does not
yet comprehend constraints involving multiple symbols, so it's possible
to calculate a VLA size that's negative or 0. A LIT is added to catch
regressions, and this change simply bails if a VLA size of 0 or less is
calculated.
Reviewers: balazske, NoQ, martong, baloghadamsoftware, Szelethus, gamesh411
Reviewed By: balazske, NoQ, Szelethus
Subscribers: xazax.hun, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, Charusso, ASDenysPetrov, cfe-commits, dkrupp
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80903
The checker currently supports only a whitelist of block-enumeration
methods which are known to internally clear an autorelease pool.
Extend this checker to detect writes within the scope of explicit
@autoreleasepool statements.
rdar://25301111
Differential Revision: https://reviews.llvm.org/D81072
Idiomatic objc using ARC will generate this expression regularly due to
NSError out-param passing. Providing an implementation for this
expression allows the analyzer to explore many more codepaths in ARC
projects.
The current implementation is not perfect but the differences are hopefully
subtle enough to not cause much problems.
rdar://63918914
Differential Revision: https://reviews.llvm.org/D81071
In the added testfile, the from argument was recognized as
&Element{SymRegion{reg_$0<long * global_a>},-1 S64b,long}
instead of
reg_$0<long * global_a>.
Summary:
In this patch I am trying to get rid of the `Irrelevant` types from the
signatures of the functions from the standard C library. For that I've
introduced `lookupType()` to be able to lookup arbitrary types in the global
scope. This makes it possible to define the signatures precisely.
Note 1) `fread`'s signature is now fixed to have the proper `FILE *restrict`
type when C99 is the language.
Note 2) There are still existing `Irrelevant` types, but they are all from
POSIX. I am planning to address those together with the missing POSIX functions
(in D79433).
Reviewers: xazax.hun, NoQ, Szelethus, balazske
Subscribers: whisperity, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, gamesh411, Charusso, steakhal, ASDenysPetrov, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80016
Summary:
Further develop the buffer size argumentum constraint so it can handle sizes
that we can get by multiplying two variables.
Reviewers: Szelethus, NoQ, steakhal
Subscribers: whisperity, xazax.hun, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, gamesh411, Charusso, ASDenysPetrov, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77148
Summary:
Introducing a new argument constraint to confine buffer sizes. It is typical in
C APIs that a parameter represents a buffer and another param holds the size of
the buffer (or the size of the data we want to handle from the buffer).
Reviewers: NoQ, Szelethus, Charusso, steakhal
Subscribers: whisperity, xazax.hun, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, gamesh411, ASDenysPetrov, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77066
Summary:
New logic tries to narrow possible result values of the remainder operation
based on its operands and their ranges. It also tries to be conservative
with negative operands because according to the standard the sign of
the result is implementation-defined.
rdar://problem/44978988
Differential Revision: https://reviews.llvm.org/D80117
Summary:
Previously the current solver started reasoning about bitwise AND
expressions only when one of the operands is a constant. However,
very similar logic could be applied to ranges. This commit addresses
this shortcoming. Additionally, it refines how we deal with negative
operands.
rdar://problem/54359410
Differential Revision: https://reviews.llvm.org/D79434
Summary:
Previously the current solver started reasoning about bitwise OR
expressions only when one of the operands is a constant. However,
very similar logic could be applied to ranges. This commit addresses
this shortcoming. Additionally, it refines how we deal with negative
operands.
Differential Revision: https://reviews.llvm.org/D79336
Summary:
This change introduces a new component to unite all of the reasoning
we have about operations on ranges in the analyzer's solver.
In many cases, we might conclude that the range for a symbolic operation
is much more narrow than the type implies. While reasoning about
runtime conditions (especially in loops), we need to support more and
more of those little pieces of logic. The new component mostly plays
a role of an organizer for those, and allows us to focus on the actual
reasoning about ranges and not dispatching manually on the types of the
nested symbolic expressions.
Differential Revision: https://reviews.llvm.org/D79232
Summary:
CompoundLiteralRegions have been properly modeled before, but
'getBindingForElement` was not changed to accommodate this change
properly.
rdar://problem/46144644
Differential Revision: https://reviews.llvm.org/D78990
Summary:
According to the standard, after a `wread` or `fwrite` call the file position
becomes "indeterminate". It is assumable that a next read or write causes
undefined behavior, so a (fatal error) warning is added for this case.
The indeterminate position can be cleared by some operations, for example
`fseek` or `freopen`, not with `clearerr`.
Reviewers: Szelethus, baloghadamsoftware, martong, NoQ, xazax.hun, dcoughlin
Reviewed By: Szelethus
Subscribers: rnkovacs, NoQ, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, gamesh411, Charusso, martong, ASDenysPetrov, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80018
If you remember the mail [1] I sent out about how I envision the future of the
already existing checkers to look dependencywise, one my main points was that no
checker that emits diagnostics should be a dependency. This is more problematic
for some checkers (ahem, RetainCount [2]) more than for others, like this one.
The MallocChecker family is a mostly big monolithic modeling class some small
reporting checkers that only come to action when we are constructing a warning
message, after the actual bug was detected. The implication of this is that
NewDeleteChecker doesn't really do anything to depend on, so this change was
relatively simple.
The only thing that complicates this change is that FreeMemAux (MallocCheckers
method that models general memory deallocation) returns after calling a bug
reporting method, regardless whether the report was ever emitted (which may not
always happen, for instance, if the checker responsible for the report isn't
enabled). This return unfortunately happens before cleaning up the maps in the
GDM keeping track of the state of symbols (whether they are released, whether
that release was successful, etc). What this means is that upon disabling some
checkers, we would never clean up the map and that could've lead to false
positives, e.g.:
error: 'warning' diagnostics seen but not expected:
File clang/test/Analysis/NewDelete-intersections.mm Line 66: Potential leak of memory pointed to by 'p'
File clang/test/Analysis/NewDelete-intersections.mm Line 73: Potential leak of memory pointed to by 'p'
File clang/test/Analysis/NewDelete-intersections.mm Line 77: Potential leak of memory pointed to by 'p'
error: 'warning' diagnostics seen but not expected:
File clang/test/Analysis/NewDelete-checker-test.cpp Line 111: Undefined or garbage value returned to caller
File clang/test/Analysis/NewDelete-checker-test.cpp Line 200: Potential leak of memory pointed to by 'p'
error: 'warning' diagnostics seen but not expected:
File clang/test/Analysis/new.cpp Line 137: Potential leak of memory pointed to by 'x'
There two possible approaches I had in mind:
Make bug reporting methods of MallocChecker returns whether they succeeded, and
proceed with the rest of FreeMemAux if not,
Halt execution with a sink node upon failure. I decided to go with this, as
described in the code.
As you can see from the removed/changed test files, before the big checker
dependency effort landed, there were tests to check for all the weird
configurations of enabled/disabled checkers and their messy interactions, I
largely repurposed these.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-August/063070.html
[2] http://lists.llvm.org/pipermail/cfe-dev/2019-August/063205.html
Differential Revision: https://reviews.llvm.org/D77474
Similarly to other patches of mine, I'm trying to uniformize the checker
interface so that dependency checkers don't emit diagnostics. The checker that
made me most anxious so far was definitely RetainCount, because it is definitely
impacted by backward compatibility concerns, and implements a checker hierarchy
that is a lot different to other examples of similar size. Also, I don't have
authority, nor expertise regarding ObjC related code, so I welcome any
objection/discussion!
Differential Revision: https://reviews.llvm.org/D78099
As per http://lists.llvm.org/pipermail/cfe-dev/2019-August/063215.html, lets get rid of this option.
It presents 2 issues that have bugged me for years now:
* OSObject is NOT a boolean option. It in fact has 3 states:
* osx.OSObjectRetainCount is enabled but OSObject it set to false: RetainCount
regards the option as disabled.
* sx.OSObjectRetainCount is enabled and OSObject it set to true: RetainCount
regards the option as enabled.
* osx.OSObjectRetainCount is disabled: RetainCount regards the option as
disabled.
* The hack involves directly modifying AnalyzerOptions::ConfigTable, which
shouldn't even be public in the first place.
This still isn't really ideal, because it would be better to preserve the option
and remove the checker (we want visible checkers to be associated with
diagnostics, and hidden options like this one to be associated with changing how
the modeling is done), but backwards compatibility is an issue.
Differential Revision: https://reviews.llvm.org/D78097
Summary:
This fixes https://bugs.llvm.org/show_bug.cgi?id=41588
RangeSet Negate function shall handle unsigned ranges as well as signed ones.
RangeSet getRangeForMinusSymbol function shall use wider variety of ranges, not only concrete value ranges.
RangeSet Intersect functions shall not produce assertions.
Changes:
Improved safety of RangeSet::Intersect function. Added isEmpty() check to prevent an assertion.
Added support of handling unsigned ranges to RangeSet::Negate and RangeSet::getRangeForMinusSymbol.
Extended RangeSet::getRangeForMinusSymbol to return not only range sets with single value [n,n], but with wide ranges [n,m].
Added unit test for Negate function.
Added regression tests for unsigned values.
Differential Revision: https://reviews.llvm.org/D77802
When loop counter is a function parameter "isPossiblyEscaped" will not find
the variable declaration which lead to hitting "llvm_unreachable".
Parameters of reference type should be escaped like global variables;
otherwise treat them as unescaped.
Patch by Abbas Sabra!
Differential Revision: https://reviews.llvm.org/D80171
iAs listed in the summary D77846, we have 5 different categories of bugs we're
checking for in CallAndMessage. I think the documentation placed in the code
explains my thought process behind my decisions quite well.
A non-obvious change I had here is removing the entry for
CallAndMessageUnInitRefArg. In fact, I removed the CheckerNameRef typed field
back in D77845 (it was dead code), so that checker didn't really exist in any
meaningful way anyways.
Differential Revision: https://reviews.llvm.org/D77866
Summary:
Stream functions `fread` and `fwrite` are evaluated
and preconditions checked.
A new bug type is added for a (non fatal) warning if `fread`
is called in EOF state.
Reviewers: Szelethus, NoQ, dcoughlin, baloghadamsoftware, martong, xazax.hun
Reviewed By: Szelethus
Subscribers: rnkovacs, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, gamesh411, Charusso, martong, ASDenysPetrov, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80015
The title and the included test file sums everything up -- the only thing I'm
mildly afraid of is whether anyone actually depends on the weird behavior of
HTMLDiagnostics pretending to be TextDiagnostics if an output directory is not
supplied. If it is, I guess we would need to resort to tiptoeing around the
compatibility flag.
Differential Revision: https://reviews.llvm.org/D76510
It was enabled by default accidentally; still missing some important
features. Also it needs a better package because it doesn't boil down to
API modeling.
Differential Revision: https://reviews.llvm.org/D80213
I think anyone who added a checker config wondered why is there a need
to test this. Its just a chore when adding a new config, so I removed
it.
To give some historic insight though, we used to not list **all**
options, but only those explicitly added to AnalyzerOptions, such as the
ones specified on the command line. However, past this change (and
arguably even before that) this line makes little sense.
There is an argument to be made against the entirety of
analyzer-config.c test file, but since this commit fixes some builtbots
and is landing without review, I wouldn't like to be too invasive.
The very essence of MallocChecker lies in 2 overload sets: the FreeMemAux
functions and the MallocMemAux functions. The former houses most of the error
checking as well (aside from leaks), such as incorrect deallocation. There, we
check whether the argument's MemSpaceRegion is the heap or unknown, and if it
isn't, we know we encountered a bug (aside from a corner case patched by
@balazske in D76830), as specified by MEM34-C.
In ReallocMemAux, which really is the combination of FreeMemAux and
MallocMemAux, we incorrectly early returned if the memory argument of realloc is
non-symbolic. The problem is, one of the cases where this happens when we know
precisely what the region is, like an array, as demonstrated in the test file.
So, lets get rid of this false negative :^)
Side note, I dislike the warning message and the associated checker name, but
I'll address it in a later patch.
Differential Revision: https://reviews.llvm.org/D79415
Summary:
Variable-length array (VLA) should have a size that fits into
a size_t value. According to the standard: "std::size_t can
store the maximum size of a theoretically possible object of
any type (including array)" (this is applied to C too).
The size expression is evaluated at the definition of the
VLA type even if this is a typedef.
The evaluation of the size expression in itself might cause
problems if it overflows.
Reviewers: Szelethus, baloghadamsoftware, martong, gamesh411
Reviewed By: Szelethus, martong, gamesh411
Subscribers: whisperity, rnkovacs, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, gamesh411, Charusso, martong, ASDenysPetrov, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D79330
One of the pain points in simplifying MallocCheckers interface by gradually
changing to CallEvent is that a variety of C++ allocation and deallocation
functionalities are modeled through preStmt<...> where CallEvent is unavailable,
and a single one of these callbacks can prevent a mass parameter change.
This patch introduces a new CallEvent, CXXDeallocatorCall, which happens after
preStmt<CXXDeleteExpr>, and can completely replace that callback as
demonstrated.
Differential Revision: https://reviews.llvm.org/D75430
Summary:
If a given parameter in a FunctionDecl has a nonull attribute then the NonNull
constraint in StdCLibraryFunctionsChecker has the same effect as
NonNullParamChecker. I think it is better to emit diagnostics from the simpler
checker. By making NonNullParamChecker as a dependency, in these cases it will
be the first to emit a diagnostic and to stop the analysis on that path.
Reviewers: Szelethus, NoQ, baloghadamsoftware, balazske, steakhal
Subscribers: whisperity, xazax.hun, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, gamesh411, Charusso, ASDenysPetrov, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D79420
The comment in Checkers.td explains whats going on. As StreamChecker grows,
expect a need to have smaller checkers out of it, but let that be a worry for
later.
Differential Revision: https://reviews.llvm.org/D78120
Summary:
Nonnull attribute can be applied to non-pointers. This caused assertion
failures in NonNullParamChecker when we tried to *assume* such parameters
to be non-zero.
rdar://problem/63150074
Differential Revision: https://reviews.llvm.org/D79843
Summary:
Some function path may lead to crash.
Fixed using local variable outside the scope through a pointer.
Fixed minor misspellings.
Added regression test.
This patch covers a bug https://bugs.llvm.org/show_bug.cgi?id=41485
Reviewed By: baloghadamsoftware
Differential Revision: https://reviews.llvm.org/D78289
Summary:
Objective-C Class objects can be used to do a dynamic dispatch on
class methods. The analyzer had a few places where we tried to overcome
the dynamic nature of it and still guess the actual function that
is being called. That was done mostly using some simple heuristics
covering the most widespread cases (e.g. [[self class] classmethod]).
This solution introduces a way to track types represented by Class
objects and work with that instead of direct AST matching.
rdar://problem/50739539
Differential Revision: https://reviews.llvm.org/D78286
Summary:
Array size expressions in typedef statements with a VLA
(variable-length array) are handled from now as in plain
(non-typedef) VLA declarations.
Type-aliases with VLA are handled too
(but main focus is on C code).
Reviewers: Szelethus, aaron.ballman, NoQ, xazax.hun
Reviewed By: aaron.ballman, xazax.hun
Subscribers: rnkovacs, NoQ, efriedma, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, gamesh411, Charusso, martong, ASDenysPetrov, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77809
Summary:
Add an option to enable on-demand parsing of needed ASTs during CTU analysis.
Two options are introduced. CTUOnDemandParsing enables the feature, and
CTUOnDemandParsingDatabase specifies the path to a compilation database, which
has all the necessary information to generate the ASTs.
Reviewers: martong, balazske, Szelethus, xazax.hun
Subscribers: ormris, mgorny, whisperity, xazax.hun, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, Charusso, steakhal, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D75665
Static analyzer has a mechanism of clearing redundant nodes when
analysis hits a certain threshold with a number of nodes in exploded
graph (default is 1000). It is similar to GC and aims removing nodes
not useful for analysis. Unfortunately nodes corresponding to array
subscript expressions (that actively participate in data propagation)
get removed during the cleanup. This might prevent the analyzer from
generating useful notes about where it thinks the data came from.
This fix is pretty much consistent with the way analysis works
already. Lvalue "interestingness" stands for the analyzer's
possibility of tracking values through them.
Differential Revision: https://reviews.llvm.org/D78638
We want to trust user type annotations and stop assuming pointers declared
as nonnull still can be null. This functionality is implemented as part
of NonNullParamChecker because it already checks parameter attributes.
Whenever we start analyzing a new function, we assume that all parameters
with 'nonnull' attribute are indeed non-null.
Patch by Valeriy Savchenko!
Differential Revision: https://reviews.llvm.org/D77806
We want to trust user type annotations and stop assuming pointers declared
as _Nonnull still can be null. This functionality is implemented as part
of NullabilityChecker as it already tracks non-null types.
Patch by Valeriy Savchenko!
Differential Revision: https://reviews.llvm.org/D77722
Exactly what it says on the tin! The included testfile demonstrates why this is
important -- for C++ dynamic memory operators, we don't always recognize custom,
or even standard-specified new/delete operators as CXXAllocatorCall or
CXXDeallocatorCall.
Differential Revision: https://reviews.llvm.org/D77391
Exactly what it says on the tin! There is no reason I think not to have this.
Also, I added test files for checkers that emit warning under the wrong name.
Differential Revision: https://reviews.llvm.org/D76605
Summary:
I wanted to extend the diagnostics of the CStringChecker with taintedness.
This requires the CStringChecker to be refactored to support a more flexible
reporting mechanism.
This patch does only refactorings, such:
- eliminates always false parameters (like WarnAboutSize)
- reduces the number of parameters
- makes strong types differentiating *source* and *destination* buffers
(same with size expressions)
- binds the argument expression and the index, making diagnostics accurate
and easy to emit
- removes a bunch of default parameters to make it more readable
- remove random const char* warning message parameters, making clear where
and what is going to be emitted
Note that:
- CheckBufferAccess now checks *only* one buffer, this removed about 100 LOC
code duplication
- not every function was refactored to use the /new/ strongly typed API, since
the CString related functions are really closely coupled monolithic beasts,
I will refactor them separately
- all tests are preserved and passing; only the message changed at some places.
In my opinion, these messages are holding the same information.
I would also highlight that this refactoring caught a bug in
clang/test/Analysis/string.c:454 where the diagnostic did not reflect reality.
This catch backs my effort on simplifying this monolithic CStringChecker.
Reviewers: NoQ, baloghadamsoftware, Szelethus, rengolin, Charusso
Reviewed By: NoQ
Subscribers: whisperity, xazax.hun, szepet, rnkovacs, a.sidorin,
mikhail.ramalho, donat.nagy, dkrupp, Charusso, martong, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D74806
Daniel Hwang