summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer
Commit message (Collapse)AuthorAgeFilesLines
...
* [Analyzer] Fix for previous commitAdam Balogh2019-04-231-2/+2
| | | | | | | | A compilation warning was in my previous commit which broke the buildbot because it is using `-Werror` for compilation. This patch fixes this issue. llvm-svn: 358955
* [Analyzer] Instead of recording comparisons in interator checkers do an ↵Adam Balogh2019-04-231-258/+126
| | | | | | | | | | | | | | | | | | eager state split Currently iterator checkers record comparison of iterator positions and process them for keeping track the distance between them (e.g. whether a position is the same as the end position). However this makes some processing unnecessarily complex and it is not needed at all: we only need to keep track between the abstract symbols stored in these iterator positions. This patch changes this and opens the path to comparisons to the begin() and end() symbols between the container (e.g. size, emptiness) which are stored as symbols, not iterator positions. The functionality of the checker is unchanged. Differential Revision: https://reviews.llvm.org/D53701 llvm-svn: 358951
* [analyzer] Unbreak body farms in presence of multiple declarations.Artem Dergachev2019-04-231-0/+3
| | | | | | | | | | | | | | When growing a body on a body farm, it's essential to use the same redeclaration of the function that's going to be used during analysis. Otherwise our ParmVarDecls won't match the ones that are used to identify argument regions. This boils down to trusting the reasoning in AnalysisDeclContext. We shouldn't canonicalize the declaration before farming the body because it makes us not obey the sophisticated decision-making process of AnalysisDeclContext. Differential Revision: https://reviews.llvm.org/D60899 llvm-svn: 358946
* [analyzer] PR41335: Fix crash when no-store event is in a body-farmed function.Artem Dergachev2019-04-231-5/+8
| | | | | | | | | | | Stuffing invalid source locations (such as those in functions produced by body farms) into path diagnostics causes crashes. Fix a typo in a nearby function name. Differential Revision: https://reviews.llvm.org/D60808 llvm-svn: 358945
* [analyzer] PR41269: Add a bit of C++ smart pointer modeling.Artem Dergachev2019-04-234-0/+117
| | | | | | | | | | | | | Implement cplusplus.SmartPtrModeling, a new checker that doesn't emit any warnings but models methods of smart pointers more precisely. For now the only thing it does is make `(bool) P` return false when `P` is a freshly moved pointer. This addresses a false positive in the use-after-move-checker. Differential Revision: https://reviews.llvm.org/D60796 llvm-svn: 358944
* [analyzer] Move UninitializedObjectChecker out of alphaKristof Umann2019-04-191-5/+5
| | | | | | | | | Moved UninitializedObjectChecker from the 'alpha.cplusplus' to the 'optin.cplusplus' package. Differential Revision: https://reviews.llvm.org/D58573 llvm-svn: 358797
* Reapply "[analyzer] Introduce a simplified API for adding custom path notes."Artem Dergachev2019-04-194-37/+39
| | | | | | | | This reapplies commit r357323, fixing memory leak found by LSan. Differential Revision: https://reviews.llvm.org/D58367 llvm-svn: 358781
* [analyzer][NFC] Reimplement checker optionsKristof Umann2019-04-191-14/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TL;DR: * Add checker and package options to the TableGen files * Added a new class called CmdLineOption, and both Package and Checker recieved a list<CmdLineOption> field. * Added every existing checker and package option to Checkers.td. * The CheckerRegistry class * Received some comments to most of it's inline classes * Received the CmdLineOption and PackageInfo inline classes, a list of CmdLineOption was added to CheckerInfo and PackageInfo * Added addCheckerOption and addPackageOption * Added a new field called Packages, used in addPackageOptions, filled up in addPackage Detailed description: In the last couple months, a lot of effort was put into tightening the analyzer's command line interface. The main issue is that it's spectacularly easy to mess up a lenghty enough invocation of the analyzer, and the user was given no warnings or errors at all in that case. We can divide the effort of resolving this into several chapters: * Non-checker analyzer configurations: Gather every analyzer configuration into a dedicated file. Emit errors for non-existent configurations or incorrect values. Be able to list these configurations. Tighten AnalyzerOptions interface to disallow making such a mistake in the future. * Fix the "Checker Naming Bug" by reimplementing checker dependencies: When cplusplus.InnerPointer was enabled, it implicitly registered unix.Malloc, which implicitly registered some sort of a modeling checker from the CStringChecker family. This resulted in all of these checker objects recieving the name "cplusplus.InnerPointer", making AnalyzerOptions asking for the wrong checker options from the command line: cplusplus.InnerPointer:Optimisic istead of unix.Malloc:Optimistic. This was resolved by making CheckerRegistry responsible for checker dependency handling, instead of checkers themselves. * Checker options: (this patch included!) Same as the first item, but for checkers. (+ minor fixes here and there, and everything else that is yet to come) There were several issues regarding checker options, that non-checker configurations didn't suffer from: checker plugins are loaded runtime, and they could add new checkers and new options, meaning that unlike for non-checker configurations, we can't collect every checker option purely by generating code. Also, as seen from the "Checker Naming Bug" issue raised above, they are very rarely used in practice, and all sorts of skeletons fell out of the closet while working on this project. They were extremely problematic for users as well, purely because of how long they were. Consider the following monster of a checker option: alpha.cplusplus.UninitializedObject:CheckPointeeInitialization=false While we were able to verify whether the checker itself (the part before the colon) existed, any errors past that point were unreported, easily resulting in 7+ hours of analyses going to waste. This patch, similarly to how dependencies were reimplemented, uses TableGen to register checker options into Checkers.td, so that Checkers.inc now contains entries for both checker and package options. Using the preprocessor, Checkers.inc is converted into code in CheckerRegistry, adding every builtin (checkers and packages that have an entry in the Checkers.td file) checker and package option to the registry. The new addPackageOption and addCheckerOption functions expose the same functionality to statically-linked non-builtin and plugin checkers and packages as well. Emitting errors for incorrect user input, being able to list these options, and some other functionalies will land in later patches. Differential Revision: https://reviews.llvm.org/D57855 llvm-svn: 358752
* [analyzer] Fix an assertion failure if plugins added dependenciesKristof Umann2019-04-191-10/+20
| | | | | | | | | | | | | | | | | | | Ideally, there is no reason behind not being able to depend on checkers that come from a different plugin (or on builtin checkers) -- however, this is only possible if all checkers are added to the registry before resolving checker dependencies. Since I used a binary search in my addDependency method, this also resulted in an assertion failure (due to CheckerRegistry::Checkers not being sorted), since the function used by plugins to register their checkers (clang_registerCheckers) calls addDependency. This patch resolves this issue by only noting which dependencies have to established when addDependency is called, and resolves them at a later stage when no more checkers are added to the registry, by which point CheckerRegistry::Checkers is already sorted. Differential Revision: https://reviews.llvm.org/D59461 llvm-svn: 358750
* [analyzer] Fix -Wunused-local-typedef after rC358695Fangrui Song2019-04-191-5/+2
| | | | llvm-svn: 358729
* [analyzer] Make default bindings to variables actually work.Artem Dergachev2019-04-181-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Default RegionStore bindings represent values that can be obtained by loading from anywhere within the region, not just the specific offset within the region that they are said to be bound to. For example, default-binding a character \0 to an int (eg., via memset()) means that the whole int is 0, not just that its lower byte is 0. Even though memset and bzero were modeled this way, it didn't work correctly when applied to simple variables. Eg., in int x; memset(x, 0, sizeof(x)); we did produce a default binding, but were unable to read it later, and 'x' was perceived as an uninitialized variable even after memset. At the same time, if we replace 'x' with a variable of a structure or array type, accessing fields or elements of such variable was working correctly, which was enough for most cases. So this was only a problem for variables of simple integer/enumeration/floating-point/pointer types. Fix loading default bindings from RegionStore for regions of simple variables. Add a unit test to document the API contract as well. Differential Revision: https://reviews.llvm.org/D60742 llvm-svn: 358722
* [analyzer][NFC] Prefer binary searches in CheckerRegistryKristof Umann2019-04-181-22/+29
| | | | | | Differential Revision: https://reviews.llvm.org/D59459 llvm-svn: 358695
* [analyzer][NFC] Clang-format CheckerRegistryKristof Umann2019-04-181-39/+37
| | | | | | Differential Revision: https://reviews.llvm.org/D59458 llvm-svn: 358694
* [analyzer][NFC] Use capital variable names, move methods out-of-line, rename ↵Kristof Umann2019-04-182-117/+149
| | | | | | | | | | | | some in CheckerRegistry There are barely any lines I haven't changed in these files, so I think I could might as well leave it in an LLVM coding style conforming state. I also renamed 2 functions and moved addDependency out of line to ease on followup patches. Differential Revision: https://reviews.llvm.org/D59457 llvm-svn: 358676
* [analyzer] PR41185: Fix regression where __builtin_* functions weren't ↵Kristof Umann2019-04-171-0/+4
| | | | | | | | | | | | | | | | | | | | | recognized For the following code snippet: void builtin_function_call_crash_fixes(char *c) { __builtin_strncpy(c, "", 6); __builtin_memset(c, '\0', (0)); __builtin_memcpy(c, c, 0); } security.insecureAPI.DeprecatedOrUnsafeBufferHandling caused a regression, as it didn't recognize functions starting with __builtin_. Fixed exactly that. I wanted to modify an existing test file, but the two I found didn't seem like perfect candidates. While I was there, I prettified their RUN: lines. Differential Revision: https://reviews.llvm.org/D59812 llvm-svn: 358609
* [analyzer] Escape pointers stored into top-level parameters with destructors.Artem Dergachev2019-04-131-34/+30
| | | | | | | | | | | | | | | | | | | | | | Writing stuff into an argument variable is usually equivalent to writing stuff to a local variable: it will have no effect outside of the function. There's an important exception from this rule: if the argument variable has a non-trivial destructor, the destructor would be invoked on the parent stack frame, exposing contents of the otherwise dead argument variable to the caller. If such argument is the last place where a pointer is stored before the function exits and the function is the one we've started our analysis from (i.e., we have no caller context for it), we currently diagnose a leak. This is incorrect because the destructor of the argument still has access to the pointer. The destructor may deallocate the pointer or even pass it further. Treat writes into such argument regions as "escapes" instead, suppressing spurious memory leak reports but not messing with dead symbol removal. Differential Revision: https://reviews.llvm.org/D60112 llvm-svn: 358321
* [analyzer] NoStoreFuncVisitor: Suppress reports with no-store in system headers.Artem Dergachev2019-04-051-22/+49
| | | | | | | | | | | | | | | | | The idea behind this heuristic is that normally the visitor is there to inform the user that a certain function may fail to initialize a certain out-parameter. For system header functions this is usually dictated by the contract, and it's unlikely that the header function has accidentally forgot to put the value into the out-parameter; it's more likely that the user has intentionally skipped the error check. Warnings on skipped error checks are more like security warnings; they aren't necessarily useful for all users, and they should instead be introduced on a per-API basis. Differential Revision: https://reviews.llvm.org/D60107 llvm-svn: 357810
* Make SourceManager::createFileID(UnownedTag, ...) take a const ↵Nico Weber2019-04-042-3/+3
| | | | | | | | | | | | | | | | | | | | | llvm::MemoryBuffer* Requires making the llvm::MemoryBuffer* stored by SourceManager const, which in turn requires making the accessors for that return const llvm::MemoryBuffer*s and updating all call sites. The original motivation for this was to use it and fix the TODO in CodeGenAction.cpp's ConvertBackendLocation() by using the UnownedTag version of createFileID, and since llvm::SourceMgr* hands out a const llvm::MemoryBuffer* this is required. I'm not sure if fixing the TODO this way actually works, but this seems like a good change on its own anyways. No intended behavior change. Differential Revision: https://reviews.llvm.org/D60247 llvm-svn: 357724
* Revert "[analyzer] Toning down invalidation a bit".Artem Dergachev2019-04-031-17/+5
| | | | | | | | | | | | | | | This reverts commit r352473. The overall idea is great, but it seems to cause unintented consequences when not only Region Store invalidation but also pointer escape mechanism was accidentally affected. Based on discussions in https://reviews.llvm.org/D58121#1452483 and https://reviews.llvm.org/D57230#1434161 Differential Revision: https://reviews.llvm.org/D57230 llvm-svn: 357620
* [analyzer] When failing to evaluate a __builtin_constant_p, presume it's false.Artem Dergachev2019-04-031-1/+9
| | | | | | | | | | | | | | | | | | | | | __builtin_constant_p(x) is a compiler builtin that evaluates to 1 when its argument x is a compile-time constant and to 0 otherwise. In CodeGen it is simply lowered to the respective LLVM intrinsic. In the Analyzer we've been trying to delegate modeling to Expr::EvaluateAsInt, which is allowed to sometimes fail for no apparent reason. When it fails, let's conservatively return false. Modeling it as false is pretty much never wrong, and it is only required to return true on a best-effort basis, which every user should expect. Fixes VLAChecker false positives on code that tries to emulate static asserts in C by constructing a VLA of dynamic size -1 under the assumption that this dynamic size is actually a constant in the sense of __builtin_constant_p. Differential Revision: https://reviews.llvm.org/D60110 llvm-svn: 357557
* Fix compiler warning, remove extra ";" [NFC]Mikael Holmen2019-04-021-1/+1
| | | | | | | | | At least gcc 7.4 complained with ../tools/clang/lib/StaticAnalyzer/Checkers/Taint.cpp:26:53: warning: extra ';' [-Wpedantic] TaintTagType); ^ llvm-svn: 357461
* Range-style std::find{,_if} -> llvm::find{,_if}. NFCFangrui Song2019-03-312-6/+5
| | | | llvm-svn: 357359
* [analyzer] MIGChecker: Add support for more deallocator APIs.Artem Dergachev2019-03-291-0/+22
| | | | | | Differential Revision: https://reviews.llvm.org/D59914 llvm-svn: 357335
* Revert "[analyzer] Introduce a simplified API for adding custom path notes."Artem Dergachev2019-03-294-39/+37
| | | | | | | | | | This reverts commit r357323. ASan leaks found by a buildbot :) Differential Revision: https://reviews.llvm.org/D58367 llvm-svn: 357332
* [analyzer] PR41239: Fix a crash on invalid source location in ↵Artem Dergachev2019-03-291-1/+1
| | | | | | | | | | | | | | | | | NoStoreFuncVisitor. It turns out that SourceManager::isInSystemHeader() crashes when an invalid source location is passed into it. Invalid source locations are relatively common: not only they come from body farms, but also, say, any function in C that didn't come with a forward declaration would have an implicit forward declaration with invalid source locations. There's a more comfy API for us to use in the Static Analyzer: CallEvent::isInSystemHeader(), so just use that. Differential Revision: https://reviews.llvm.org/D59901 llvm-svn: 357329
* [analyzer] Move taint API from ProgramState to a separate header. NFC.Artem Dergachev2019-03-2912-237/+361
| | | | | | | | | | It is now an inter-checker communication API, similar to the one that connects MallocChecker/CStringChecker/InnerPointerChecker: simply a set of setters and getters for a state trait. Differential Revision: https://reviews.llvm.org/D59861 llvm-svn: 357326
* [analyzer] PR37501: Disable assertion for logical op short circuit evaluation.Artem Dergachev2019-03-291-2/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The transfer function for the CFG element that represents a logical operation computes the value of the operation and does nothing else. The element appears after all the short circuit decisions were made, so they don't need to be made again at this point. Because our expression evaluation is imprecise, it is often hard to discriminate between: (1) we don't know the value of the RHS because we failed to evaluate it and (2) we don't know the value of the RHS because it didn't need to be evaluated. This is hard because it depends on our knowledge about the value of the LHS (eg., if LHS is true, then RHS in (LHS || RHS) doesn't need to be computed) but LHS itself may have been evaluated imprecisely and we don't know whether it is true or not. Additionally, the Analyzer wouldn't necessarily even remember what the value of the LHS was because theoretically it's not really necessary to know it for any future evaluations. In order to work around these issues, the transfer function for logical operations consists in looking at the ExplodedGraph we've constructed so far in order to figure out from which CFG direction did we arrive here. Such post-factum backtracking that doesn't involve looking up LHS and RHS values is usually possible. However sometimes it fails because when we deduplicate exploded nodes with the same program point and the same program state we may end up in a situation when we reached the same program point from two or more different directions. By removing the assertion, we admit that the procedure indeed sometimes fails to work. When it fails, we also admit that we don't know the value of the logical operator. Differential Revision: https://reviews.llvm.org/D59857 llvm-svn: 357325
* [analyzer] Introduce a simplified API for adding custom path notes.Artem Dergachev2019-03-294-37/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Almost all path-sensitive checkers need to tell the user when something specific to that checker happens along the execution path but does not constitute a bug on its own. For instance, a call to operator delete in C++ has consequences that are specific to a use-after-free bug. Deleting an object is not a bug on its own, but when the Analyzer finds an execution path on which a deleted object is used, it'll have to explain to the user when exactly during that path did the deallocation take place. Historically such custom notes were added by implementing "bug report visitors". These visitors were post-processing bug reports by visiting every ExplodedNode along the path and emitting path notes whenever they noticed that a change that is relevant to a bug report occurs within the program state. For example, it emits a "memory is deallocated" note when it notices that a pointer changes its state from "allocated" to "deleted". The "visitor" approach is powerful and efficient but hard to use because such preprocessing implies that the developer first models the effects of the event (say, changes the pointer's state from "allocated" to "deleted" as part of operator delete()'s transfer function) and then forgets what happened and later tries to reverse-engineer itself and figure out what did it do by looking at the report. The proposed approach tries to avoid discarding the information that was available when the transfer function was evaluated. Instead, it allows the developer to capture all the necessary information into a closure that will be automatically invoked later in order to produce the actual note. This should reduce boilerplate and avoid very painful logic duplication. On the technical side, the closure is a lambda that's put into a special kind of a program point tag, and a special bug report visitor visits all nodes in the report and invokes all note-producing closures it finds along the path. For now it is up to the lambda to make sure that the note is actually relevant to the report. For instance, a memory deallocation note would be irrelevant when we're reporting a division by zero bug or if we're reporting a use-after-free of a different, unrelated chunk of memory. The lambda can figure these thing out by looking at the bug report object that's passed into it. A single checker is refactored to make use of the new functionality: MIGChecker. Its program state is trivial, making it an easy testing ground for the first version of the API. Differential Revision: https://reviews.llvm.org/D58367 llvm-svn: 357323
* Make helper functions static. NFC.Benjamin Kramer2019-03-281-2/+2
| | | | llvm-svn: 357187
* [Analyzer] Constraint Manager - Calculate Effective Range for DifferencesAdam Balogh2019-03-281-5/+28
| | | | | | | | | | | | | | | | | | | | | Since rL335814, if the constraint manager cannot find a range set for `A - B` (where `A` and `B` are symbols) it looks for a range for `B - A` and returns it negated if it exists. However, if a range set for both `A - B` and `B - A` is stored then it only returns the first one. If we both use `A - B` and `B - A`, these expressions behave as two totally unrelated symbols. This way we miss some useful deductions which may lead to false negatives or false positives. This tiny patch changes this behavior: if the symbolic expression the constraint manager is looking for is a difference `A - B`, it tries to retrieve the range for both `A - B` and `B - A` and if both exists it returns the intersection of range `A - B` and the negated range of `B - A`. This way every time a checker applies new constraints to the symbolic difference or to its negated it always affects both the original difference and its negated. Differential Revision: https://reviews.llvm.org/D55007 llvm-svn: 357167
* Frontend: Remove CompilerInstance::VirtualFileSystem, NFCDuncan P. N. Exon Smith2019-03-261-2/+0
| | | | | | | | | | | | | | | Remove CompilerInstance::VirtualFileSystem and CompilerInstance::setVirtualFileSystem, instead relying on the VFS in the FileManager. CompilerInstance and its clients already went to some trouble to make these match. Now they are guaranteed to match. As part of this, I added a VFS parameter (defaults to nullptr) to CompilerInstance::createFileManager, to avoid repeating construction logic in clients that just wanted to customize the VFS. https://reviews.llvm.org/D59377 llvm-svn: 357037
* [CFG] [analyzer] pr41142: C++17: Skip transparent InitListExprs in ExprEngine.Artem Dergachev2019-03-261-1/+1
| | | | | | | | | | | | | | | | | | | r356634 didn't fix all the problems caused by r356222 - even though simple constructors involving transparent init-list expressions are now evaluated precisely, many more complicated constructors aren't, for other reasons. The attached test case is an example of a constructor that will never be evaluated precisely - simply because there isn't a constructor there (instead, the program invokes run-time undefined behavior by returning without a return statement that should have constructed the return value). Fix another part of the problem for such situations: evaluate transparent init-list expressions transparently, so that to avoid creating ill-formed "transparent" nonloc::CompoundVals. Differential Revision: https://reviews.llvm.org/D59622 llvm-svn: 356969
* Moved everything SMT-related to LLVM and updated the cmake scripts.Mikhail R. Gadelha2019-03-254-852/+21
| | | | | | Differential Revision: https://reviews.llvm.org/D54978 llvm-svn: 356929
* [analyzer] ConditionBRVisitor: Unknown condition evaluation supportCsaba Dabis2019-03-161-7/+12
| | | | | | | | | | | | | | | | | | | | | | Summary: If the constraint information is not changed between two program states the analyzer has not learnt new information and made no report. But it is possible to happen because we have no information at all. The new approach evaluates the condition to determine if that is the case and let the user know we just `Assuming...` some value. Reviewers: NoQ, george.karpenkov Reviewed By: NoQ Subscribers: llvm-commits, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, gsd, gerazo Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D57410 llvm-svn: 356323
* [analyzer] ConditionBRVisitor: Remove GDM checkingCsaba Dabis2019-03-162-6/+10
| | | | | | | | | | | | | | | | | | | | Summary: Removed the `GDM` checking what could prevent reports made by this visitor. Now we rely on constraint changes instead. (It reapplies 356318 with a feature from 356319 because build-bot failure.) Reviewers: NoQ, george.karpenkov Reviewed By: NoQ Subscribers: cfe-commits, jdoerfert, gerazo, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp Tags: #clang Differential Revision: https://reviews.llvm.org/D54811 llvm-svn: 356322
* Revert "[analyzer] ConditionBRVisitor: Remove GDM checking"Csaba Dabis2019-03-162-8/+6
| | | | | | This reverts commit f962485adad9d646511fd3240c0408d9554e6784. llvm-svn: 356321
* Revert "[analyzer] ConditionBRVisitor: Unknown condition evaluation support"Csaba Dabis2019-03-161-14/+7
| | | | | | This reverts commit 0fe67a61cd4aec13c7969a179517f1cc06ab05cd. llvm-svn: 356320
* [analyzer] ConditionBRVisitor: Unknown condition evaluation supportCsaba Dabis2019-03-161-7/+14
| | | | | | | | | | | | | | | | Summary: If the constraint information is not changed between two program states the analyzer has not learnt new information and made no report. But it is possible to happen because we have no information at all. The new approach evaluates the condition to determine if that is the case and let the user know we just 'Assuming...' some value. Reviewers: NoQ, george.karpenkov Reviewed By: NoQ Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, gsd, gerazo Tags: #clang Differential Revision: https://reviews.llvm.org/D57410 llvm-svn: 356319
* [analyzer] ConditionBRVisitor: Remove GDM checkingCsaba Dabis2019-03-162-6/+8
| | | | | | | | | | | | | | | | Summary: Removed the `GDM` checking what could prevent reports made by this visitor. Now we rely on constraint changes instead. Reviewers: NoQ, george.karpenkov Reviewed By: NoQ Subscribers: jdoerfert, gerazo, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp Tags: #clang Differential Revision: https://reviews.llvm.org/D54811 llvm-svn: 356318
* Add missing override specifier [NFC]Aaron Puchert2019-03-151-1/+1
| | | | | | | This should fix a -Winconsistent-missing-override warning that is only visible when Z3 is enabled. llvm-svn: 356228
* [analyzer] Support C++17 aggregates with bases without constructors.Artem Dergachev2019-03-151-1/+46
| | | | | | | | | | | | RegionStore now knows how to bind a nonloc::CompoundVal that represents the value of an aggregate initializer when it has its initial segment of sub-values correspond to base classes. Additionally, fixes the crash from pr40022. Differential Revision: https://reviews.llvm.org/D59054 llvm-svn: 356222
* [analyzer] Fix an assertation failure for invalid sourcelocation, add a new ↵Kristof Umann2019-03-142-1/+42
| | | | | | | | | | | | | | | | | | | | | | | | debug checker For a rather short code snippet, if debug.ReportStmts (added in this patch) was enabled, a bug reporter visitor crashed: struct h { operator int(); }; int k() { return h(); } Ultimately, this originated from PathDiagnosticLocation::createMemberLoc, as it didn't handle the case where it's MemberExpr typed parameter returned and invalid SourceLocation for MemberExpr::getMemberLoc. The solution was to find any related valid SourceLocaion, and Stmt::getBeginLoc happens to be just that. Differential Revision: https://reviews.llvm.org/D58777 llvm-svn: 356161
* Remove unused variable to silence compiler warning [NFC]Mikael Holmen2019-03-141-2/+1
| | | | | | The only use of MI was removed in r356142. llvm-svn: 356152
* [analyzer] Fix function macro crashKristof Umann2019-03-141-4/+22
| | | | | | | | Re-commit D57893. Differential Revision: https://reviews.llvm.org/D57893 llvm-svn: 356142
* [Analyzer] Update the LLVM license in PointerSortingChecker.cppMandeep Singh Grang2019-03-131-5/+4
| | | | llvm-svn: 356086
* [Analyzer] Skip symbolic regions based on conjured symbols in comparison of ↵Adam Balogh2019-03-131-3/+46
| | | | | | | | | | | | | | | | the containers of iterators Checking whether two regions are the same is a partially decidable problem: either we know for sure that they are the same or we cannot decide. A typical case for this are the symbolic regions based on conjured symbols. Two different conjured symbols are either the same or they are different. Since we cannot decide this and want to reduce false positives as much as possible we exclude these regions whenever checking whether two containers are the same at iterator mismatch check. Differential Revision: https://reviews.llvm.org/D53754 llvm-svn: 356049
* Revert "[analyzer] Fix function macro crash"Kristof Umann2019-03-121-20/+4
| | | | | | | | | Buildbot breaks when LLVm is compiled with memory sanitizer. WARNING: MemorySanitizer: use-of-uninitialized-value #0 0xa3d16d8 in getMacroNameAndPrintExpansion(blahblah) lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:903:11 llvm-svn: 355911
* [analyzer] Fix function macro crashKristof Umann2019-03-121-4/+20
| | | | | | | | | | | | | | | | | | | When there is a functor-like macro which is passed as parameter to another "function" macro then its parameters are not listed at the place of expansion: #define foo(x) int bar() { return x; } #define hello(fvar) fvar(0) hello(foo) int main() { 1 / bar(); } Expansion of hello(foo) asserted Clang, because it expected an l_paren token in the 3rd line after "foo", since it is a function-like token. Patch by Tibor Brunner! Differential Revision: https://reviews.llvm.org/D57893 llvm-svn: 355903
* [Analyzer] Checker for non-determinism caused by sorting of pointer-like ↵Mandeep Singh Grang2019-03-082-0/+115
| | | | | | | | | | | | | | | | | | | | elements Summary: Added a new category of checkers for non-determinism. Added a checker for non-determinism caused due to sorting containers with pointer-like elements. Reviewers: NoQ, george.karpenkov, whisperity, Szelethus Reviewed By: NoQ, Szelethus Subscribers: Charusso, baloghadamsoftware, jdoerfert, donat.nagy, dkrupp, martong, dblaikie, MTC, Szelethus, mgorny, xazax.hun, szepet, rnkovacs, a.sidorin, mikhail.ramalho, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D50488 llvm-svn: 355720
* [analyzer] Fix infinite recursion in printing macrosKristof Umann2019-03-081-11/+41
| | | | | | | | | | | | | | | | | | | | In the commited testfile, macro expansion (the one implemented for the plist output) runs into an infinite recursion. The issue originates from the algorithm being faulty, as in #define value REC_MACRO_FUNC(value) the "value" is being (or at least attempted) expanded from the same macro. The solved this issue by gathering already visited macros in a set, which does resolve the crash, but will result in an incorrect macro expansion, that would preferably be fixed down the line. Patch by Tibor Brunner! Differential Revision: https://reviews.llvm.org/D57891 llvm-svn: 355705
OpenPOWER on IntegriCloud