summaryrefslogtreecommitdiffstats
path: root/clang/unittests/Analysis
Commit message (Collapse)AuthorAgeFilesLines
* [NFC] format unittest for ExprMutAnalyzerJonas Toth2020-01-101-29/+24
| | | | | | This formatting is a preparation for review in https://reviews.llvm.org/D54943 to separate pure formatting changes from actual testing changes.
* [CFG] Fix an assertion failure with static initializersGabor Horvath2019-12-232-13/+38
| | | | | | | | | | | | | The CFGBlock::getLastCondition was not prepared for static initializer branches. This patch also revamps CFG unit tests. Earlier the lifetime of the AST was smaller than the CFG. So all the AST pointers within the CFG blocks were dangling. This was OK, since none of the tests dereferenced those pointers. This was, however, a timed bomb. There were patches in the past that were reverted partially due to this problem. Differential revision: https://reviews.llvm.org/D71791
* [CFG] Introduce CFGElementRef, a wrapper that knows it's position in a CFGBlockKristof Umann2019-08-141-0/+133
| | | | | | | | | | | | | | | | Previously, collecting CFGElements in a set was practially impossible, because both CFGBlock::operator[] and both the iterators returned it by value. One workaround would be to collect the iterators instead, but they don't really capture the concept of an element, and elements from different iterator types are incomparable. This patch introduces CFGElementRef, a wrapper around a (CFGBlock, Index) pair, and a variety of new iterators and iterator ranges to solve this problem. I guess you could say that this patch took a couple iterations to get right :^) Differential Revision: https://reviews.llvm.org/D65196 llvm-svn: 368883
* Removed the test case added in D63538 due to windows buildbot failuresKristof Umann2019-07-051-38/+0
| | | | llvm-svn: 365209
* [analyzer][IDF] Add a control dependency calculator + a new debug checkerKristof Umann2019-07-051-0/+91
| | | | | | | | | | | | | | | | | | | | | | | I intend to improve the analyzer's bug reports by tracking condition expressions. 01 bool b = messyComputation(); 02 int i = 0; 03 if (b) // control dependency of the bug site, let's explain why we assume val 04 // to be true 05 10 / i; // warn: division by zero I'll detail this heuristic in the followup patch, strictly related to this one however: * Create the new ControlDependencyCalculator class that uses llvm::IDFCalculator to (lazily) calculate control dependencies for Clang's CFG. * A new debug checker debug.DumpControlDependencies is added for lit tests * Add unittests Differential Revision: https://reviews.llvm.org/D62619 llvm-svn: 365197
* Fix a buildbot failure due to the AST's lifetime ending before the testKristof Umann2019-07-051-17/+3
| | | | llvm-svn: 365181
* [analyzer][Dominators][NFC] Add unit testsKristof Umann2019-07-054-51/+174
| | | | | | Differential Revision: https://reviews.llvm.org/D62611 llvm-svn: 365179
* [CFG] Add a new function to get the proper condition of a CFGBlockKristof Umann2019-07-051-0/+52
| | | | | | | | | | | | | getTerminatorCondition() returned a condition that may be outside of the block, while the new function returns the proper one: if (A && B && C) {} Return C instead of A && B && C. Differential Revision: https://reviews.llvm.org/D63538 llvm-svn: 365177
* cmake: Add CLANG_LINK_CLANG_DYLIB optionTom Stellard2019-07-031-1/+1
| | | | | | | | | | | | | | | | Summary: Setting CLANG_LINK_CLANG_DYLIB=ON causes clang tools to link against libclang_shared.so instead of the individual component libraries. Reviewers: mgorny, beanz, smeenai, phosek, sylvestre.ledru Subscribers: arphaman, cfe-commits, llvm-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63503 llvm-svn: 365092
* [analyzer] Treat functions without run-time branches as "small".Artem Dergachev2019-04-301-14/+45
| | | | | | | | | | | | | | | | | | Currently we always inline functions that have no branches, i.e. have exactly three CFG blocks: ENTRY, some code, EXIT. This makes sense because when there are no branches, it means that there's no exponential complexity introduced by inlining such function. Such functions also don't trigger various fundamental problems with our inlining mechanism, such as the problem of inlined defensive checks. Sometimes the CFG may contain more blocks, but in practice it still has linear structure because all directions (except, at most, one) of all branches turned out to be unreachable. When this happens, still treat the function as "small". This is useful, in particular, for dealing with C++17 if constexpr. Differential Revision: https://reviews.llvm.org/D61051 llvm-svn: 359531
* Fix some clang analysis tests passing arguments incorrectlyReid Kleckner2019-03-071-3/+3
| | | | llvm-svn: 355625
* [analyzer] handle modification of vars inside an expr with comma operatorPetar Jovanovic2019-03-071-0/+131
| | | | | | | | | | | | | | | | | We should track mutation of a variable within a comma operator expression. Current code in ExprMutationAnalyzer does not handle it. This will handle cases like: (a, b) ++ < == b is modified (a, b) = c < == b is modifed Patch by Djordje Todorovic. Differential Revision: https://reviews.llvm.org/D58894 llvm-svn: 355605
* [clang] add tests to ExprMutAnalyzer that reproduced a crash in ASTMatchersJonas Toth2019-01-211-0/+19
| | | | | | | | | | | | | | | | | Summary: This patch adds two unit-tests that are the result of reducing a crashing TU when running ExprMutAnalyzer over it. They are added only to ensure the regression that has been fixed with https://reviews.llvm.org/D56444 don't creep back. Reviewers: aaron.ballman, sammccall, rsmith, george.karpenkov Reviewed By: sammccall Subscribers: baloghadamsoftware, a.sidorin, Szelethus, donat.nagy, dkrupp, cfe-commits Differential Revision: https://reviews.llvm.org/D56917 llvm-svn: 351743
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-193-12/+9
| | | | | | | | | | | | | | | | | 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
* Fix use-after-free bug in Tooling.Alexander Kornienko2019-01-081-1/+4
| | | | | | | | | | | | | | | | | | | Summary: `buildASTFromCodeWithArgs()` was creating a memory buffer referencing a stack-allocated string. This diff changes the implementation to copy the code string into the memory buffer so that said buffer owns the memory. Patch by Yitzhak Mandelbaum. Reviewers: alexfh Reviewed By: alexfh Subscribers: cfe-commits, EricWF Differential Revision: https://reviews.llvm.org/D55765 llvm-svn: 350638
* Add explicit dependency on clangSerialization for a bunch of components to ↵Fangrui Song2018-12-121-0/+1
| | | | | | | | | | | | | | | fix -DBUILD_SHARED_LIBS=on build This is a more thorough fix of rC348911. The story about -DBUILD_SHARED_LIBS=on build after rC348907 (Move PCHContainerOperations from Frontend to Serialization) is: 1. libclangSerialization.so defines PCHContainerReader dtor, ... 2. clangFrontend and clangTooling define classes inheriting from PCHContainerReader, thus their DSOs have undefined references on PCHContainerReader dtor 3. Components depending on either clangFrontend or clangTooling cannot be linked unless they have explicit dependency on clangSerialization due to the default linker option -z defs. The explicit dependency could be avoided if libclang{Frontend,Tooling}.so had these undefined references. This patch adds the explicit dependency on clangSerialization to make them build. llvm-svn: 348915
* [NFC] Declare instead of define non-void functions in unit tests.Shuai Wang2018-09-191-6/+6
| | | | llvm-svn: 342586
* [analyzer] Fix nullptr access when processing instantiated function in ↵Shuai Wang2018-09-191-0/+30
| | | | | | ExprMutationAnalyzer. llvm-svn: 342562
* [NFC] Fix uncompilable test cases of ExprMutationAnalyzer.Shuai Wang2018-09-191-311/+265
| | | | | | And ensure future test cases doesn't have compile errors. llvm-svn: 342525
* [analyzer] Treat std::{move,forward} as casts in ExprMutationAnalyzer.Shuai Wang2018-09-171-23/+115
| | | | | | | | | | | | | | | Summary: This is a follow up of D52008 and should make the analyzer being able to handle perfect forwardings in real world cases where forwardings are done through multiple layers of function calls with `std::forward`. Fixes PR38891. Reviewers: lebedev.ri, JonasToth, george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin, mikhail.ramalho, Szelethus, cfe-commits Differential Revision: https://reviews.llvm.org/D52120 llvm-svn: 342409
* [analyzer] Handle forwarding reference better in ExprMutationAnalyzer.Shuai Wang2018-09-141-0/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We used to treat an `Expr` mutated whenever it's passed as non-const reference argument to a function. This results in false positives in cases like this: ``` int x; std::vector<int> v; v.emplace_back(x); // `x` is passed as non-const reference to `emplace_back` ``` In theory the false positives can be suppressed with `v.emplace_back(std::as_const(x))` but that's considered overly verbose, inconsistent with existing code and spammy as diags. This diff handles such cases by following into the function definition and see whether the argument is mutated inside. Reviewers: lebedev.ri, JonasToth, george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin, mikhail.ramalho, Szelethus, cfe-commits Differential Revision: https://reviews.llvm.org/D52008 llvm-svn: 342271
* [analyzer] Add ExprMutationAnalyzerShuai Wang2018-09-112-0/+944
| | | | | | | | | | | | | | | | | | Summary: This is 1/2 of moving ExprMutationAnalyzer from clangtidy to clang/Analysis. This diff along simply copies the ExprMutationAnalyzer over with trivial modifications (e.g. include path, namespace) 2/2 will migrate existing usage of ExprMutationAnalyzer and remove the original copy inside clangtidy. Reviewers: george.karpenkov Subscribers: mgorny, xazax.hun, szepet, a.sidorin, mikhail.ramalho, Szelethus, cfe-commits, JonasToth Differential Revision: https://reviews.llvm.org/D51948 llvm-svn: 341994
* [CMake] Use PRIVATE in target_link_libraries for executablesShoaib Meenai2017-12-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently use target_link_libraries without an explicit scope specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables. Dependencies added in this way apply to both the target and its dependencies, i.e. they become part of the executable's link interface and are transitive. Transitive dependencies generally don't make sense for executables, since you wouldn't normally be linking against an executable. This also causes issues for generating install export files when using LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM library dependencies, which are currently added as interface dependencies. If clang is in the distribution components but the LLVM libraries it depends on aren't (which is a perfectly legitimate use case if the LLVM libraries are being built static and there are therefore no run-time dependencies on them), CMake will complain about the LLVM libraries not being in export set when attempting to generate the install export file for clang. This is reasonable behavior on CMake's part, and the right thing is for LLVM's build system to explicitly use PRIVATE dependencies for executables. Unfortunately, CMake doesn't allow you to mix and match the keyword and non-keyword target_link_libraries signatures for a single target; i.e., if a single call to target_link_libraries for a particular target uses one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must also be updated to use those keywords. This means we must do this change in a single shot. I also fully expect to have missed some instances; I tested by enabling all the projects in the monorepo (except dragonegg), and configuring both with and without shared libraries, on both Darwin and Linux, but I'm planning to rely on the buildbots for other configurations (since it should be pretty easy to fix those). Even after this change, we still have a lot of target_link_libraries calls that don't specify a scope keyword, mostly for shared libraries. I'm thinking about addressing those in a follow-up, but that's a separate change IMO. Differential Revision: https://reviews.llvm.org/D40823 llvm-svn: 319840
* [analyzer] Performance optimizations for the CloneCheckerRaphael Isemann2017-08-311-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch aims at optimizing the CloneChecker for larger programs. Before this patch we took around 102 seconds to analyze sqlite3 with a complexity value of 50. After this patch we now take 2.1 seconds to analyze sqlite3. The biggest performance optimization is that we now put the constraint for group size before the constraint for the complexity. The group size constraint is much faster in comparison to the complexity constraint as it only does a simple integer comparison. The complexity constraint on the other hand actually traverses each Stmt and even checks the macro stack, so it is obviously not able to handle larger amounts of incoming clones. The new order filters out all the single-clone groups that the type II constraint generates in a faster way before passing the fewer remaining clones to the complexity constraint. This reduced runtime by around 95%. The other change is that we also delay the verification part of the type II clones back in the chain of constraints. This required to split up the constraint into two parts - a verification and a hash constraint (which is also making it more similar to the original design of the clone detection algorithm). The reasoning for this is the same as before: The verification constraint has to traverse many statements and shouldn't be at the start of the constraint chain. However, as the type II hashing has to be the first step in our algorithm, we have no other choice but split this constrain into two different ones. Now our group size and complexity constrains filter out a chunk of the clones before they reach the slow verification step, which reduces the runtime by around 8%. I also kept the full type II constraint around - that now just calls it's two sub-constraints - in case someone doesn't care about the performance benefits of doing this. Reviewers: NoQ Reviewed By: NoQ Subscribers: klimek, v.g.vassilev, xazax.hun, cfe-commits Differential Revision: https://reviews.llvm.org/D34182 llvm-svn: 312222
* [analyzer] Reland r299544 "Add a modular constraint system to the CloneDetector"Artem Dergachev2017-04-062-2/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | Hopefully fix crashes by unshadowing the variable. Original commit message: A big part of the clone detection code is functionality for filtering clones and clone groups based on different criteria. So far this filtering process was hardcoded into the CloneDetector class, which made it hard to understand and, ultimately, to extend. This patch splits the CloneDetector's logic into a sequence of reusable constraints that are used for filtering clone groups. These constraints can be turned on and off and reodreder at will, and new constraints are easy to implement if necessary. Unit tests are added for the new constraint interface. This is a refactoring patch - no functional change intended. Patch by Raphael Isemann! Differential Revision: https://reviews.llvm.org/D23418 llvm-svn: 299653
* Revert "[analyzer] Add a modular constraint system to the CloneDetector"Artem Dergachev2017-04-052-113/+2
| | | | | | | | This reverts commit r299544. Crashes on tests on some buildbots. llvm-svn: 299550
* [analyzer] Add a modular constraint system to the CloneDetectorArtem Dergachev2017-04-052-2/+113
| | | | | | | | | | | | | | | | | | | | | | A big part of the clone detection code is functionality for filtering clones and clone groups based on different criteria. So far this filtering process was hardcoded into the CloneDetector class, which made it hard to understand and, ultimately, to extend. This patch splits the CloneDetector's logic into a sequence of reusable constraints that are used for filtering clone groups. These constraints can be turned on and off and reodreder at will, and new constraints are easy to implement if necessary. Unit tests are added for the new constraint interface. This is a refactoring patch - no functional change intended. Patch by Raphael Isemann! Differential Revision: https://reviews.llvm.org/D23418 llvm-svn: 299544
* [analyzer] Fix crash when building CFG with variable of incomplete typeMartin Bohme2017-03-071-1/+13
| | | | | | | | | | | | | | | | | | Summary: I've included a unit test with a function template containing a variable of incomplete type. Clang compiles this without errors (the standard does not require a diagnostic in this case). Without the fix, this case triggers the crash. Reviewers: klimek Reviewed By: klimek Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30636 llvm-svn: 297129
* CFGBuilder: Fix crash when visiting delete expression on dependent typeMartin Bohme2016-12-051-23/+45
| | | | | | | | | | | | | | Summary: CXXDeleteExpr::getDestroyedType() can return a null QualType if the destroyed type is a dependent type. This patch protects against this. Reviewers: klimek Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D27350 llvm-svn: 288665
* CFGTests: Update libdeps.NAKAMURA Takumi2016-07-081-0/+3
| | | | llvm-svn: 274885
* clang/unittests/Analysis/CFGTest.cpp: Appease msc targets with ↵NAKAMURA Takumi2016-07-081-1/+1
| | | | | | -fno-delayed-template-parsing. llvm-svn: 274879
* CFGBuilder: Fix crash when visiting a range-based for over a dependent typeAlexander Kornienko2016-07-082-0/+71
Summary: CFG generation is expected to fail in this case, but it should not crash. Also added a test that reproduces the crash. Reviewers: klimek Subscribers: cfe-commits Patch by Martin Boehme! Differential Revision: http://reviews.llvm.org/D21895 llvm-svn: 274834
OpenPOWER on IntegriCloud