|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, 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, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, 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, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, 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, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3 |
|
| #
b9bca883 |
| 11-Sep-2020 |
Kristóf Umann <[email protected]> |
[analyzer][NFC] Don't bind values to ObjCForCollectionStmt, replace it with a GDM trait
Based on the discussion in D82598#2171312. Thanks @NoQ!
D82598 is titled "Get rid of statement liveness, beca
[analyzer][NFC] Don't bind values to ObjCForCollectionStmt, replace it with a GDM trait
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
show more ...
|
|
Revision tags: llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
| #
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <[email protected]> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1 |
|
| #
c82d457d |
| 28-Sep-2018 |
George Karpenkov <[email protected]> |
[analyzer] [NFC] Remove unused parameters, as found by -Wunused-parameter
Differential Revision: https://reviews.llvm.org/D52640
llvm-svn: 343353
|
|
Revision tags: llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2 |
|
| #
3ccf14eb |
| 15-Aug-2018 |
Artem Dergachev <[email protected]> |
[analyzer] Add support for constructors of arguments.
Once CFG-side support for argument construction contexts landed in r338436, the analyzer could make use of them to evaluate argument constructor
[analyzer] Add support for constructors of arguments.
Once CFG-side support for argument construction contexts landed in r338436, the analyzer could make use of them to evaluate argument constructors properly.
When evaluated as calls, constructors of arguments now use the variable region of the parameter as their target. The corresponding stack frame does not yet exist when the parameter is constructed, and this stack frame is created eagerly.
Construction of functions whose body is unavailable and of virtual functions is not yet supported. Part of the reason is the analyzer doesn't consistently use canonical declarations o identify the function in these cases, and every re-declaration or potential override comes with its own set of parameter declarations. Also it is less important because if the function is not inlined, there's usually no benefit in inlining the argument constructor.
Differential Revision: https://reviews.llvm.org/D49443
llvm-svn: 339745
show more ...
|
|
Revision tags: llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1 |
|
| #
04b9dc58 |
| 08-Mar-2018 |
George Karpenkov <[email protected]> |
[analyzer] Correctly model iteration through "nil" objects
Previously, iteration through nil objects which resulted from objc-messages being set to nil were modeled incorrectly.
There are a couple
[analyzer] Correctly model iteration through "nil" objects
Previously, iteration through nil objects which resulted from objc-messages being set to nil were modeled incorrectly.
There are a couple of notes about this patch:
In principle, ExprEngineObjC might be left untouched IFF osx.loops checker is enabled. I however think that we should not do something completely incorrect depending on what checkers are left on. We should evaluate and potentially remove altogether the isConsumedExpr performance heuristic, as it seems very fragile.
rdar://22205149
Differential Revision: https://reviews.llvm.org/D44178
llvm-svn: 326982
show more ...
|
|
Revision tags: llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1 |
|
| #
b570195c |
| 13-Jan-2017 |
Anna Zaks <[email protected]> |
[analyzer] Add LocationContext as a parameter to checkRegionChanges
This patch adds LocationContext to checkRegionChanges and removes wantsRegionChangeUpdate as it was unused.
A patch by Krzysztof
[analyzer] Add LocationContext as a parameter to checkRegionChanges
This patch adds LocationContext to checkRegionChanges and removes wantsRegionChangeUpdate as it was unused.
A patch by Krzysztof Wiśniewski!
Differential Revision: https://reviews.llvm.org/D27090
llvm-svn: 291869
show more ...
|
|
Revision tags: llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1, llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1, llvmorg-3.8.1, llvmorg-3.8.1-rc1, llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1, llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1 |
|
| #
676a58c9 |
| 15-Sep-2015 |
Devin Coughlin <[email protected]> |
[analyzer] Restore behavior change introduced by r247657.
r247657 fixed warnings about unused variables when compiling without asserts but changed behavior. This commit restores the old behavior but
[analyzer] Restore behavior change introduced by r247657.
r247657 fixed warnings about unused variables when compiling without asserts but changed behavior. This commit restores the old behavior but still suppresses the warnings.
llvm-svn: 247660
show more ...
|
| #
f14c2508 |
| 15-Sep-2015 |
NAKAMURA Takumi <[email protected]> |
ExprEngineObjC.cpp: Fix warnings. [-Wunused-variable]
llvm-svn: 247657
|
| #
ca5ab2b0 |
| 15-Sep-2015 |
Devin Coughlin <[email protected]> |
[analyzer] Skip Pre/Post handlers for ObjC calls when receiver is nil.
In Objective-C, method calls with nil receivers are essentially no-ops. They do not fault (although the returned value may be g
[analyzer] Skip Pre/Post handlers for ObjC calls when receiver is nil.
In Objective-C, method calls with nil receivers are essentially no-ops. They do not fault (although the returned value may be garbage depending on the declared return type and architecture). Programmers are aware of this behavior and will complain about a false alarm when the analyzer diagnoses API violations for method calls when the receiver is known to be nil.
Rather than require each individual checker to be aware of this behavior and suppress a warning when the receiver is nil, this commit changes ExprEngineObjC so that VisitObjCMessage skips calling checker pre/post handlers when the receiver is definitely nil. Instead, it adds a new event, ObjCMessageNil, that is only called in that case.
The CallAndMessageChecker explicitly cares about this case, so I've changed it to add a callback for ObjCMessageNil and moved the logic in PreObjCMessage that handles nil receivers to the new callback.
rdar://problem/18092611
Differential Revision: http://reviews.llvm.org/D12123
llvm-svn: 247653
show more ...
|
| #
dc6be245 |
| 14-Sep-2015 |
Gabor Horvath <[email protected]> |
[Static Analyzer] Relaxing a caching out related assert.
Differential Revision: http://reviews.llvm.org/D12818
llvm-svn: 247598
|
| #
3a0678e3 |
| 08-Sep-2015 |
Ted Kremenek <[email protected]> |
[analyzer] Apply whitespace cleanups by Honggyu Kim.
llvm-svn: 246978
|
|
Revision tags: llvmorg-3.7.0, llvmorg-3.7.0-rc4, llvmorg-3.7.0-rc3, llvmorg-3.7.0-rc2, llvmorg-3.7.0-rc1, llvmorg-3.6.2, llvmorg-3.6.2-rc1, llvmorg-3.6.1, llvmorg-3.6.1-rc1, llvmorg-3.5.2, llvmorg-3.5.2-rc1, llvmorg-3.6.0, llvmorg-3.6.0-rc4, llvmorg-3.6.0-rc3, llvmorg-3.6.0-rc2, llvmorg-3.6.0-rc1, llvmorg-3.5.1, llvmorg-3.5.1-rc2, llvmorg-3.5.1-rc1, llvmorg-3.5.0, llvmorg-3.5.0-rc4, llvmorg-3.5.0-rc3, llvmorg-3.5.0-rc2, llvmorg-3.5.0-rc1 |
|
| #
0dbb783c |
| 27-May-2014 |
Craig Topper <[email protected]> |
[C++11] Use 'nullptr'. StaticAnalyzer edition.
llvm-svn: 209642
|
|
Revision tags: llvmorg-3.4.2, llvmorg-3.4.2-rc1, llvmorg-3.4.1, llvmorg-3.4.1-rc2, llvmorg-3.4.1-rc1 |
|
| #
867ea1d4 |
| 02-Mar-2014 |
Benjamin Kramer <[email protected]> |
[C++11] Replace llvm::tie with std::tie.
llvm-svn: 202639
|
|
Revision tags: llvmorg-3.4.0, llvmorg-3.4.0-rc3, llvmorg-3.4.0-rc2, llvmorg-3.4.0-rc1, llvmorg-3.3.1-rc1, llvmorg-3.3.0, llvmorg-3.3.0-rc3, llvmorg-3.3.0-rc2, llvmorg-3.3.0-rc1 |
|
| #
05785d16 |
| 20-Feb-2013 |
David Blaikie <[email protected]> |
Include llvm::Optional in clang/Basic/LLVM.h
Post-commit CR feedback from Jordan Rose regarding r175594.
llvm-svn: 175679
|
| #
2fdacbc5 |
| 20-Feb-2013 |
David Blaikie <[email protected]> |
Replace SVal llvm::cast support to be well-defined.
See r175462 for another example/more details.
llvm-svn: 175594
|
|
Revision tags: llvmorg-3.2.0 |
|
| #
642e0638 |
| 06-Dec-2012 |
Jordan Rose <[email protected]> |
[analyzer] Remove unused fields from ExprEngine.
'currStmt', 'CleanedState', and 'EntryNode' were being set, but only ever used locally.
llvm-svn: 169529
|
|
Revision tags: llvmorg-3.2.0-rc3, llvmorg-3.2.0-rc2, llvmorg-3.2.0-rc1 |
|
| #
92375ada |
| 01-Oct-2012 |
Jordan Rose <[email protected]> |
[analyzer] Allow ObjC ivar lvalues where the base is nil.
By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a
[analyzer] Allow ObjC ivar lvalues where the base is nil.
By analogy with C structs, this seems to be legal, if probably discouraged. It's only if the ivar is read from or written to that there's a problem. Running a program that gets the "address" of an instance variable does in fact return the offset when the base "object" is nil.
This isn't a full revert because r164442 includes some diagnostic tweaks as well; those have been kept.
This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4.
llvm-svn: 164960
show more ...
|
| #
1d64a498 |
| 22-Sep-2012 |
Jordan Rose <[email protected]> |
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue.
Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path not
[analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue.
Like with struct fields, we want to catch cases like this early, so that we can produce better diagnostics and path notes:
PointObj *p = nil; int *px = &p->_x; // should warn here *px = 1;
llvm-svn: 164442
show more ...
|
| #
8b3f9386 |
| 13-Sep-2012 |
Ted Kremenek <[email protected]> |
Refactor logic in ExprEngine for detecting 'noreturn' methods in NSException to a helper object in libAnalysis that can also be used by Sema. Not sure if the predicate name 'isImplicitNoReturn' is t
Refactor logic in ExprEngine for detecting 'noreturn' methods in NSException to a helper object in libAnalysis that can also be used by Sema. Not sure if the predicate name 'isImplicitNoReturn' is the best one, but we can massage that later.
No functionality change.
llvm-svn: 163759
show more ...
|
| #
5481cfef |
| 08-Sep-2012 |
Jordan Rose <[email protected]> |
[analyzer] ObjCSelfInitChecker should always clean up in postCall checks.
ObjCSelfInitChecker stashes information in the GDM to persist it across function calls; it is stored in pre-call checks and
[analyzer] ObjCSelfInitChecker should always clean up in postCall checks.
ObjCSelfInitChecker stashes information in the GDM to persist it across function calls; it is stored in pre-call checks and retrieved post-call. The post-call check is supposed to clear out the stored state, but was failing to do so in cases where the call did not have a symbolic return value.
This was actually causing the inappropriate cache-out from r163361. Per discussion with Anna, we should never actually cache out when assuming the receiver of an Objective-C message is non-nil, because we guarded that node generation by checking that the state has changed. Therefore, the only states that could reach this exact ExplodedNode are ones that should have merged /before/ making this assumption.
r163361 has been reverted and the test case removed, since it won't actually test anything interesting now.
llvm-svn: 163449
show more ...
|
| #
7e97996f |
| 06-Sep-2012 |
Jordan Rose <[email protected]> |
[analyzer] Don't crash if we cache out while evaluating an ObjC message.
A bizarre series of coincidences led us to generate a previously-seen node in the middle of processing an Objective-C message
[analyzer] Don't crash if we cache out while evaluating an ObjC message.
A bizarre series of coincidences led us to generate a previously-seen node in the middle of processing an Objective-C message, where we assume the receiver is non-nil. We were assuming that such an assumption would never "cache out" like this, and blithely went on using a null ExplodedNode as the predecessor for the next step in evaluation.
Although the test case committed here is complicated, this could in theory happen in other ways as well, so the correct fix is just to test if the non-nil assumption results in an ExplodedNode we've seen before.
<rdar://problem/12243648>
llvm-svn: 163361
show more ...
|
| #
d94854a4 |
| 22-Aug-2012 |
Ted Kremenek <[email protected]> |
Rename 'currentX' to 'currX' throughout analyzer and libAnalysis. Also rename 'getCurrentBlockCounter()' to 'blockCount()'.
This ripples a bunch of code simplifications; mostly aesthetic, but makes
Rename 'currentX' to 'currX' throughout analyzer and libAnalysis. Also rename 'getCurrentBlockCounter()' to 'blockCount()'.
This ripples a bunch of code simplifications; mostly aesthetic, but makes the code a bit tighter.
llvm-svn: 162349
show more ...
|
| #
d227833c |
| 22-Aug-2012 |
Ted Kremenek <[email protected]> |
Rename 'getConjuredSymbol*' to 'conjureSymbol*'.
No need to have the "get", the word "conjure" is a verb too! Getting a conjured symbol is the same as conjuring one up.
This shortening is largely c
Rename 'getConjuredSymbol*' to 'conjureSymbol*'.
No need to have the "get", the word "conjure" is a verb too! Getting a conjured symbol is the same as conjuring one up.
This shortening is largely cosmetic, but just this simple changed cleaned up a handful of lines, making them less verbose.
llvm-svn: 162348
show more ...
|
| #
4b4613cb |
| 20-Aug-2012 |
Jordan Rose <[email protected]> |
[analyzer] Replace boolean IsSink parameters with 'generateSink' methods.
Generating a sink is significantly different behavior from generating a normal node, and a simple boolean parameter can be r
[analyzer] Replace boolean IsSink parameters with 'generateSink' methods.
Generating a sink is significantly different behavior from generating a normal node, and a simple boolean parameter can be rather opaque. Per offline discussion with Anna, adding new generation methods is the clearest way to communicate intent.
No functionality change.
llvm-svn: 162215
show more ...
|
| #
fcd016e5 |
| 30-Jul-2012 |
Jordan Rose <[email protected]> |
[analyzer] Only allow CallEvents to be created by CallEventManager.
This ensures that it is valid to reference-count any CallEvents, and we won't accidentally try to reclaim a CallEvent that lives o
[analyzer] Only allow CallEvents to be created by CallEventManager.
This ensures that it is valid to reference-count any CallEvents, and we won't accidentally try to reclaim a CallEvent that lives on the stack. It also hides an ugly switch statement for handling CallExprs!
There should be no functionality change here.
llvm-svn: 160986
show more ...
|