summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Core
Commit message (Collapse)AuthorAgeFilesLines
...
* Fixes issue introduced by r331556.Alexander Kornienko2018-05-091-3/+5
| | | | | | | | | | Closes bug: https://bugs.llvm.org/show_bug.cgi?id=37357 Patch by Rafael Stahl! Differential revision: https://reviews.llvm.org/D46633 llvm-svn: 331870
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-097-25/+25
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* Fix a couple places that immediately called operator-> on the result of ↵Craig Topper2018-05-051-1/+1
| | | | | | | | dyn_cast. It looks like it safe to just use cast for both cases. llvm-svn: 331578
* [analyzer] Remove untested code in evalLoad.Artem Dergachev2018-05-041-37/+0
| | | | | | No functional change intended. llvm-svn: 331565
* [analyzer] Invalidate union regions properly. Don't hesitate to load later.Artem Dergachev2018-05-041-6/+1
| | | | | | | | | | | | | | | | | | | We weren't invalidating our unions correctly. The previous behavior in invalidateRegionsWorker::VisitCluster() was to direct-bind an UnknownVal to the union (at offset 0). For that reason we were never actually loading default bindings from our unions, because there never was any default binding to load, and the value that is presumed when there's no default binding to load is usually completely incorrect (eg. UndefinedVal for stack unions). The new behavior is to default-bind a conjured symbol (of irrelevant type) to the union that's being invalidated, similarly to what we do for structures and classes. Then it becomes safe to load the value properly. Differential Revision: https://reviews.llvm.org/D45241 llvm-svn: 331563
* [analyzer] pr36458: Fix retrieved value cast for symbolic void pointers.Artem Dergachev2018-05-041-0/+14
| | | | | | | | | | | | | C allows us to write any bytes into any memory region. When loading weird bytes from memory regions of known types, the analyzer is required to make sure that the loaded value makes sense by casting it to an appropriate type. Fix such cast for loading values that represent void pointers from non-void pointer type places. Differential Revision: https://reviews.llvm.org/D46415 llvm-svn: 331562
* [analyzer] pr18953: Split C++ zero-initialization from default initialization.Artem Dergachev2018-05-045-34/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | The bindDefault() API of the ProgramState allows setting a default value for reads from memory regions that were not preceded by writes. It was used for implementing C++ zeroing constructors (i.e. default constructors that boil down to setting all fields of the object to 0). Because differences between zeroing consturctors and other forms of default initialization have been piling up (in particular, zeroing constructors can be called multiple times over the same object, probably even at the same offset, requiring a careful and potentially slow cleanup of previous bindings in the RegionStore), we split the API in two: bindDefaultInitial() for modeling initial values and bindDefaultZero() for modeling zeroing constructors. This fixes a few assertion failures from which the investigation originated. The imperfect protection from both inability of the RegionStore to support binding extents and lack of information in ASTRecordLayout has been loosened because it's, well, imperfect, and it is unclear if it fixing more than it was breaking. Differential Revision: https://reviews.llvm.org/D46368 llvm-svn: 331561
* [analyzer] pr37209: Fix casts of glvalues to references.Artem Dergachev2018-05-041-0/+7
| | | | | | | | | | | | | | | Many glvalue expressions aren't of their respective reference type - they are simply glvalues of their value type. This was causing problems when we were trying to obtain type of the original expression while evaluating certain glvalue bit-casts. Fixed by artificially forging a reference type to provide to the casting procedure. Differential Revision: https://reviews.llvm.org/D46224 llvm-svn: 331558
* [analyzer] Treat more const variables and fields as known contants.Artem Dergachev2018-05-042-3/+52
| | | | | | | | | | | | | | | | When loading from a variable or a field that is declared as constant, the analyzer will try to inspect its initializer and constant-fold it. Upon success, the analyzer would skip normal load and return the respective constant. The new behavior also applies to fields/elements of brace-initialized structures and arrays. Patch by Rafael Stahl! Differential Revision: https://reviews.llvm.org/D45774 llvm-svn: 331556
* [analyzer] NFC: Remove unused parameteer of StoreManager::CastRetrievedVal().Artem Dergachev2018-05-042-17/+5
| | | | llvm-svn: 331496
* Track the result of evaluating a computed noexcept specification on theRichard Smith2018-05-031-2/+2
| | | | | | | | | | | | | | FunctionProtoType. We previously re-evaluated the expression each time we wanted to know whether the type is noexcept or not. We now evaluate the expression exactly once. This is not quite "no functional change": it fixes a crasher bug during AST deserialization where we would try to evaluate the noexcept specification in a situation where we have not deserialized sufficient portions of the AST to permit such evaluation. llvm-svn: 331428
* [analyzer] Fix filename in cross-file HTML reportMalcolm Parsons2018-05-021-1/+3
| | | | | | | | | | | | | | | | | Summary: The filename is currently taken from the start of the path, while the line and column are taken from the end of the path. This didn't matter until cross-file path reporting was added. Reviewers: george.karpenkov, dcoughlin, vlad.tsyrklevich Reviewed By: george.karpenkov, vlad.tsyrklevich Subscribers: xazax.hun, szepet, a.sidorin, cfe-commits Differential Revision: https://reviews.llvm.org/D45611 llvm-svn: 331361
* PR37189 Fix incorrect end source location and spelling for a split '>>' token.Richard Smith2018-04-302-2/+2
| | | | | | | | | | | | | | | | | | When a '>>' token is split into two '>' tokens (in C++11 onwards), or (as an extension) when we do the same for other tokens starting with a '>', we can't just use a location pointing to the first '>' as the location of the split token, because that would result in our miscomputing the length and spelling for the token. As a consequence, for example, a refactoring replacing 'A<X>' with something else would sometimes replace one character too many, and similarly diagnostics highlighting a template-id source range would highlight one character too many. Fix this by creating an expansion range covering the first character of the '>>' token, whose spelling is '>'. For this to work, we generalize the expansion range of a macro FileID to be either a token range (the common case) or a character range (used in this new case). llvm-svn: 331155
* [analyzer] Fix operator delete[] array-type-sub-expression handling.Artem Dergachev2018-04-271-2/+4
| | | | | | | | | | | | Avoid crash when the sub-expression of operator delete[] is of array type. This is not the same as simply using a delete[] syntax. We're still not properly calling destructors in this case in the analyzer. Differential Revision: https://reviews.llvm.org/D46146 llvm-svn: 331014
* [analyzer] Fix a crash on lifetime extension through aggregate initialization.Artem Dergachev2018-04-252-6/+22
| | | | | | | | | | | | If 'A' is a C++ aggregate with a reference field of type 'C', in code like A a = { C() }; C() is lifetime-extended by 'a'. The analyzer wasn't expecting this pattern and crashing. Additionally, destructors aren't added in the CFG for this case, so for now we shouldn't be inlining the constructor for C(). Differential Revision: https://reviews.llvm.org/D46037 llvm-svn: 330882
* [analyzer] Enable analysis of WebKit "unified sources".Artem Dergachev2018-04-253-12/+13
| | | | | | | | | | | | | | | | | | | Normally the analyzer begins path-sensitive analysis from functions within the main file, even though the path is allowed to go through any functions within the translation unit. When a recent version of WebKit is compiled, the "unified sources" technique is used, that assumes #including multiple code files into a single main file. Such file would have no functions defined in it, so the analyzer wouldn't be able to find any entry points for path-sensitive analysis. This patch pattern-matches unified file names that are similar to those used by WebKit and allows the analyzer to find entry points in the included code files. A more aggressive/generic approach is being planned as well. Differential Revision: https://reviews.llvm.org/D45839 llvm-svn: 330876
* [analyzer] Add support for the note diagnostic pieces to plist output format.Artem Dergachev2018-04-241-29/+97
| | | | | | | | | | | | | | | | | Note diagnostic pieces are an additional way of highlighting code sections to the user. They aren't part of the normal path diagnostic sequence. They can also be attached to path-insensitive reports. Notes are already supported by the text output and scan-build. Expanding our machine-readable plist output format to be able to represent notes opens up the possibility for various analyzer GUIs to pick them up. Patch by Umann Kristóf! Differential Revision: https://reviews.llvm.org/D45407 llvm-svn: 330766
* [analyzer] Don't crash on printing ConcreteInt of size >64 bitsAleksei Sidorin2018-04-231-7/+3
| | | | | | | | Printing of ConcreteInts with size >64 bits resulted in assertion failure in get[Z|S]ExtValue() because these methods are only allowed to be used with integers of 64 max bit width. This patch fixes the issue. llvm-svn: 330605
* [analyzer] Move `TaintBugVisitor` from `GenericTaintChecker.cpp` to ↵Henry Wong2018-04-231-0/+21
| | | | | | | | | | | | | | | | `BugReporterVisitors.h`. Summary: `TaintBugVisitor` is a universal visitor, and many checkers rely on it, such as `ArrayBoundCheckerV2.cpp`, `DivZeroChecker.cpp` and `VLASizeChecker.cpp`. Moving `TaintBugVisitor` to `BugReporterVisitors.h` enables other checker can also track where `tainted` value came from. Reviewers: NoQ, george.karpenkov, xazax.hun Reviewed By: george.karpenkov Subscribers: szepet, rnkovacs, a.sidorin, cfe-commits, MTC Differential Revision: https://reviews.llvm.org/D45682 llvm-svn: 330596
* [analyzer] When we fail to evaluate a pointer cast, escape the pointer.Artem Dergachev2018-04-192-34/+24
| | | | | | | | | | | | | | If a pointer cast fails (evaluates to an UnknownVal, i.e. not implemented in the analyzer) and such cast is in fact the last use of the pointer, the pointer symbol is no longer referenced by the program state and a leak is (mis-)diagnosed. "Escape" the pointer upon a failed cast, i.e. inform the checker that we can no longer reliably track it. Differential Revision: https://reviews.llvm.org/D45698 llvm-svn: 330380
* [analyzer] Do not invalidate the `this` pointer.Henry Wong2018-04-152-0/+15
| | | | | | | | | | | | | | | | | Summary: `this` pointer is not an l-value, although we have modeled `CXXThisRegion` for `this` pointer, we can only bind it once, which is when we start to inline method. And this patch fixes https://bugs.llvm.org/show_bug.cgi?id=35506. In addition, I didn't find any other cases other than loop-widen that could invalidate `this` pointer. Reviewers: NoQ, george.karpenkov, a.sidorin, seaneveson, szepet Reviewed By: NoQ Subscribers: xazax.hun, rnkovacs, cfe-commits, MTC Differential Revision: https://reviews.llvm.org/D45491 llvm-svn: 330095
* [Analyzer] Fix for SValBuilder expressions rearrangementAdam Balogh2018-04-131-0/+2
| | | | | | | | Expression rearrangement in SValBuilder (see rL329780) crashes with an assert if the type of the integer is different from the type of the symbol. This fix adds a check that prevents rearrangement in such cases. Differential Revision: https://reviews.llvm.org/D45557 llvm-svn: 330064
* [analyzer] Fix null deref in AnyFunctionCall::getRuntimeDefinitionGabor Horvath2018-04-131-16/+17
| | | | | | | | Patch by: Rafael Stahl! Differential Revision: https://reviews.llvm.org/D45564 llvm-svn: 330009
* [Analyzer] SValBuilder Comparison Rearrangement (with Restrictions and ↵Adam Balogh2018-04-112-0/+199
| | | | | | | | | | | | | | | | Analyzer Option) Since the range-based constraint manager (default) is weak in handling comparisons where symbols are on both sides it is wise to rearrange them to have symbols only on the left side. Thus e.g. A + n >= B + m becomes A - B >= m - n which enables the constraint manager to store a range m - n .. MAX_VALUE for the symbolic expression A - B. This can be used later to check whether e.g. A + k == B + l can be true, which is also rearranged to A - B == l - k so the constraint manager can check whether l - k is in the range (thus greater than or equal to m - n). The restriction in this version is the the rearrangement happens only if both the symbols and the concrete integers are within the range [min/4 .. max/4] where min and max are the minimal and maximal values of their type. The rearrangement is not enabled by default. It has to be enabled by using -analyzer-config aggressive-relational-comparison-simplification=true. Co-author of this patch is Artem Dergachev (NoQ). Differential Revision: https://reviews.llvm.org/D41938 llvm-svn: 329780
* Sort source lists in lib/StaticAnalyzer.Nico Weber2018-04-071-1/+1
| | | | llvm-svn: 329481
* Fix typos in clangAlexander Kornienko2018-04-063-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Found via codespell -q 3 -I ../clang-whitelist.txt Where whitelist consists of: archtype cas classs checkk compres definit frome iff inteval ith lod methode nd optin ot pres statics te thru Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few files that have dubious fixes reverted.) Differential revision: https://reviews.llvm.org/D44188 llvm-svn: 329399
* Make helpers static. NFC.Benjamin Kramer2018-04-042-5/+4
| | | | llvm-svn: 329170
* [StaticAnalyzer] Fix some Clang-tidy modernize and Include What You Use ↵Eugene Zelenko2018-04-032-126/+140
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 329115
* [analyzer] Fix diagnostics in callees of interesting callees.Artem Dergachev2018-04-031-9/+6
| | | | | | | | | | | | | | | removeUnneededCalls() is responsible for removing path diagnostic pieces within functions that don't contain "interesting" events. It makes bug reports much tidier. When a stack frame is known to be interesting, the function doesn't descend into it to prune anything within it, even other callees that are totally boring. Fix the function to prune boring callees in interesting stack frames. Differential Revision: https://reviews.llvm.org/D45117 llvm-svn: 329102
* [analyzer] Unroll the loop when it has a unsigned counter.Henry Wong2018-03-311-7/+9
| | | | | | | | | | | | | | | | | Summary: The original implementation in the `LoopUnrolling.cpp` didn't consider the case where the counter is unsigned. This case is only handled in `simpleCondition()`, but this is not enough, we also need to deal with the unsinged counter with the counter initialization. Since `IntegerLiteral` is `signed`, there is a `ImplicitCastExpr<IntegralCast>` in `unsigned counter = IntergerLiteral`. This patch add the `ignoringParenImpCasts()` in the `IntegerLiteral` matcher. Reviewers: szepet, a.sidorin, NoQ, george.karpenkov Reviewed By: szepet, george.karpenkov Subscribers: xazax.hun, rnkovacs, cfe-commits, MTC Differential Revision: https://reviews.llvm.org/D45086 llvm-svn: 328919
* [analyzer] Cache offset computation for MemRegionGeorge Karpenkov2018-03-311-31/+36
| | | | | | | | | | | | | Achieves almost a 200% speedup on the example where the performance of visitors was problematic. Performance on sqlite3 is unaffected. rdar://38818362 Differential Revision: https://reviews.llvm.org/D45113 llvm-svn: 328911
* [analyzer] Track null or undef values through pointer arithmetic.Artem Dergachev2018-03-301-8/+18
| | | | | | | | | | | | | | | | | | Pointer arithmetic on null or undefined pointers results in null or undefined pointers. This is obvious for undefined pointers; for null pointers it follows from our incorrect-but-somehow-working approach that declares that 0 (Loc) doesn't necessarily represent a pointer of numeric address value 0, but instead it represents any pointer that will cause a valid "null pointer dereference" issue when dereferenced. For now we've been seeing through pointer arithmetic at the original dereference expression, i.e. in bugreporter::getDerefExpr(), but not during further investigation of the value's origins in bugreporter::trackNullOrUndefValue(). The patch fixes it. Differential Revision: https://reviews.llvm.org/D45071 llvm-svn: 328896
* [CFG] [analyzer] Avoid modeling C++17 constructors that aren't fully supported.Artem Dergachev2018-03-301-6/+17
| | | | | | | | | | | | | | Not enough work has been done so far to ensure correctness of construction contexts in the CFG when C++17 copy elision is in effect, so for now we should drop construction contexts in the CFG and in the analyzer when they seem different from what we support anyway. This includes initializations with conditional operators and return values across multiple stack frames. Differential Revision: https://reviews.llvm.org/D44854 llvm-svn: 328893
* [analyzer] Better pretty-printing of regions in exploded graphGeorge Karpenkov2018-03-292-3/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D45010 llvm-svn: 328835
* [clang] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-03-272-5/+5
| | | | | | | | | | | r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. llvm-svn: 328636
* [analyzer] LoopUnrolling: update the matched assignment operatorsPeter Szecsi2018-03-271-3/+1
| | | | | | | | | Extended the matched assignment operators when checking for bound changes in a body of the loop by using the freshly added isAssignmentOperator matcher. This covers all the (current) possible assignments, tests added as well. Differential Revision: https://reviews.llvm.org/D38921 llvm-svn: 328619
* [analyzer] Do not crash in CallEvent.getReturnType()George Karpenkov2018-03-241-3/+5
| | | | | | When the call expression is not available. llvm-svn: 328406
* [analyzer] Trust _Nonnull annotations for system frameworkGeorge Karpenkov2018-03-231-5/+24
| | | | | | | | | | | Changes the analyzer to believe that methods annotated with _Nonnull from system frameworks indeed return non null objects. Local methods with such annotation are still distrusted. rdar://24291919 Differential Revision: https://reviews.llvm.org/D44341 llvm-svn: 328282
* [analyzer] [NFC] Move worklist implementation to WorkList.cppGeorge Karpenkov2018-03-233-230/+253
| | | | | | | | | | Current location is very confusing, especially because there is already WorkList.h, and other code in CoreEngine.cpp is not related to work list implementation. Differential Revision: https://reviews.llvm.org/D44759 llvm-svn: 328280
* [analyzer] Enable temporary object destructor inlining by default.Artem Dergachev2018-03-221-1/+1
| | | | | | | | | | | | When a temporary is constructed with a proper construction context, it should be safe to inline the destructor. We have added suppressions for some of the common false positives caused by such inlining, so there should be - and from my observations there indeed is - more benefit than harm from enabling destructor inlining. Differential Revision: https://reviews.llvm.org/D44721 llvm-svn: 328258
* [CFG] [analyzer] Add C++17-specific ctor-initializer construction contexts.Artem Dergachev2018-03-221-1/+2
| | | | | | | | | | CXXCtorInitializer-based constructors are also affected by the C++17 mandatory copy elision, like variable constructors and return value constructors. Extend r328248 to support those. Differential Revision: https://reviews.llvm.org/D44763 llvm-svn: 328255
* [analyzer] Remove an assertion that doesn't hold in C++17.Artem Dergachev2018-03-222-16/+42
| | | | | | | | | | | | Function return values can be constructed directly in variables or passed directly into return statements, without even an elidable copy in between. This is how the C++17 mandatory copy elision AST behaves. The behavior we'll have in such cases is the "old" behavior that we've had before we've implemented destructor inlining and proper lifetime extension support. Differential Revision: https://reviews.llvm.org/D44755 llvm-svn: 328253
* [CFG] [analyzer] Add C++17-specific variable and return construction contexts.Artem Dergachev2018-03-221-1/+5
| | | | | | | | | | | | | | | | | | | In C++17 copy elision is mandatory for variable and return value constructors (as long as it doesn't involve type conversion) which results in AST that does not contain elidable constructors in their usual places. In order to provide construction contexts in this scenario we need to cover more AST patterns. This patch makes the CFG prepared for these scenarios by: - Fork VariableConstructionContext and ReturnedValueConstructionContext into two different sub-classes (each) one of which indicates the C++17 case and contains a reference to an extra CXXBindTemporaryExpr. - Allow CFGCXXRecordTypedCall element to accept VariableConstructionContext and ReturnedValueConstructionContext as its context. Differential Revision: https://reviews.llvm.org/D44597 llvm-svn: 328248
* [analyzer] Improve performance of NoStoreFuncVisitorGeorge Karpenkov2018-03-201-19/+50
| | | | | | | | Compute modifying frames lazily on demand. Differential Revision: https://reviews.llvm.org/D44503 llvm-svn: 327935
* [analyzer] Fix the assertion failure when static globals are used in lambda ↵George Karpenkov2018-03-201-15/+13
| | | | | | | | | | | | by reference Also use the opportunity to clean up the code and remove unnecessary duplication. rdar://37625895 Differential Revision: https://reviews.llvm.org/D44594 llvm-svn: 327926
* StaticAnalyzer: fix compiler warning. NFCPavel Labath2018-03-141-1/+1
| | | | | | | | | | | | My compiler (clang-3.8) complains that the RCC variable is unused. That's not really true, as it's checked by the if-declaration, but it's also kinda true, because we don't need to declaration if we only check it in the if statement. In reality, all this means that the dyn_cast<> can be replaced by isa<>, so that's what I do here. llvm-svn: 327491
* [analyzer] Support temporaries conjured by conservatively evaluated functions.Artem Dergachev2018-03-121-14/+30
| | | | | | | | | | | | | | Properly perform destruction and lifetime extension of such temporaries. C++ object-type return values of conservatively evaluated functions are now represented as compound values of well-defined temporary object regions. The function creates a region that represents the temporary object and will later be used for destruction or materialization, invalidates it, and returns the invalidated compound value of the object. Differential Revision: https://reviews.llvm.org/D44131 llvm-svn: 327348
* [analyzer] NFC: Move the code for setting temp object lifetime into method.Artem Dergachev2018-03-122-61/+61
| | | | | | Differential Revision: https://reviews.llvm.org/D44129 llvm-svn: 327347
* [analyzer] Destroy and lifetime-extend inlined function return values properly.Artem Dergachev2018-03-121-29/+58
| | | | | | | | | | | | | | | This patch uses the newly added CFGCXXRecordTypedCall element at the call site of the caller to construct the return value within the callee directly into the caller's stack frame. This way it is also capable of populating the temporary destructor and lifetime extension maps for the temporary, which allows temporary destructors and lifetime extension to work correctly. This patch does not affect temporaries that were returned from conservatively evaluated functions. Differential Revision: https://reviews.llvm.org/D44124 llvm-svn: 327345
* [CFG] [analyzer] Add construction context to C++ return-by-value call elements.Artem Dergachev2018-03-122-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a new CFGStmt sub-class, CFGCXXRecordTypedCall, which replaces the regular CFGStmt for the respective CallExpr whenever the CFG has additional information to provide regarding the lifetime of the returned value. This additional call site information is represented by a ConstructionContext (which was previously used for CFGConstructor elements) that provides references to CXXBindTemporaryExpr and MaterializeTemporaryExpr that surround the call. This corresponds to the common C++ calling convention solution of providing the target address for constructing the return value as an auxiliary implicit argument during function call. One of the use cases for such extra context at the call site would be to perform any sort of inter-procedural analysis over the CFG that involves functions returning objects by value. In this case the elidable constructor at the return site would construct the object explained by the context at the call site, and its lifetime would also be managed by the caller, not the callee. The extra context would also be useful for properly handling the return-value temporary at the call site, even if the callee is not being analyzed inter-procedurally. Differential Revision: https://reviews.llvm.org/D44120 llvm-svn: 327343
OpenPOWER on IntegriCloud