summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Core
Commit message (Collapse)AuthorAgeFilesLines
...
* [analyzer][ctu] fix unsortable diagnosticsRafael Stahl2018-07-041-3/+7
| | | | | | | | | | | | | | Summary: In the provided test case the PathDiagnostic compare function was not able to find a difference. Reviewers: xazax.hun, NoQ, dcoughlin, george.karpenkov Reviewed By: george.karpenkov Subscribers: a_sidorin, szepet, rnkovacs, a.sidorin, mikhail.ramalho, cfe-commits Differential Revision: https://reviews.llvm.org/D48474 llvm-svn: 336275
* [analyzer] Replace the vector of ConstraintSets by a single ConstraintSet ↵Mikhail R. Gadelha2018-06-291-15/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and a function to merge ConstraintSets Now, instead of adding the constraints when they are removed, this patch adds them when they first appear and, since we walk the bug report backward, it should be the last set of ranges generated by the CSA for a given symbol. These are the number before and after the patch: ``` Project | current | patch | tmux | 283.222 | 123.052 | redis | 614.858 | 400.347 | openssl | 308.292 | 307.149 | twin | 274.478 | 245.411 | git | 547.687 | 477.335 | postgresql | 2927.495 | 2002.526 | sqlite3 | 3264.305 | 1028.416 | ``` Major speedups in tmux and sqlite (less than half of the time), redis and postgresql were about 25% faster while the rest are basically the same. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: rnkovacs, xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D48565 llvm-svn: 336002
* [analyzer] Fix wrong comparison generation of the ranges generated by the ↵Mikhail R. Gadelha2018-06-281-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | refutation manager The refutation manager is removing a true bug from the test in this patch. The problem is that the following constraint: ``` (conj_$1{struct o *}) - (reg_$3<int * r>): [-9223372036854775808, 0] ``` is encoded as: ``` (and (bvuge (bvsub $1 $3) #x8000000000000000) (bvule (bvsub $1 $3) #x0000000000000000)) ``` The issue is that unsigned comparisons (bvuge and bvule) are being generated instead of signed comparisons (bvsge and bvsle). When generating the expressions: ``` (conj_$1{p *}) - (reg_$3<int * r>) >= -9223372036854775808 ``` and ``` (conj_$1{p *}) - (reg_$3<int * r>) <= 0 ``` both -9223372036854775808 and 0 are casted to pointer type and `LTy->isSignedIntegerOrEnumerationType()` in `Z3ConstraintManager::getZ3BinExpr` only checks if the type is signed, not if it's a pointer. Reviewers: NoQ, george.karpenkov, ddcc Subscribers: rnkovacs, NoQ, george.karpenkov, ddcc, xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D48324 llvm-svn: 335926
* [Analyzer] Constraint Manager Negates DifferenceAdam Balogh2018-06-281-1/+68
| | | | | | | | If range [m .. n] is stored for symbolic expression A - B, then we can deduce the range for B - A which is [-n .. -m]. This is only true for signed types, unless the range is [0 .. 0]. Differential Revision: https://reviews.llvm.org/D35110 llvm-svn: 335814
* [analyzer] Remove redundant ';'.Artem Dergachev2018-06-281-1/+1
| | | | | | Fixes a compiler warning. No functionan change intended. llvm-svn: 335808
* [analyzer] Use sufficiently large types for index bounds calculation.Artem Dergachev2018-06-282-3/+3
| | | | | | | | | | | | | | | | | The ProgramState::assumeInBound() API is used by checkers to make an assumption that a certain array index is within the array's bounds (i.e. is greater than or equal to 0 and is less than the length of the array). When the type of the index was unspecified by the caller, it assumed that the type is 'int', which caused some indices and sizes to truncate during calculations. Use ArrayIndexTy by default instead, which is used by the analyzer to represent index types and is currently hardcoded to long long. Patch by Bevin Hansson! Differential Revision: https://reviews.llvm.org/D46944 llvm-svn: 335803
* [analyzer] Add support for pre-C++17 copy elision.Artem Dergachev2018-06-282-43/+150
| | | | | | | | | | | | | | | | r335795 adds copy elision information to CFG. This commit allows static analyzer to elide elidable copy constructors by constructing the objects that were previously subject to elidable copy directly in the target region of the copy. The chain of elided constructors may potentially be indefinitely long. This only happens when the object is being returned from a function which in turn is returned from another function, etc. NRVO is not supported yet. Differential Revision: https://reviews.llvm.org/D47671 llvm-svn: 335800
* [CFG] [analyzer] Simplify lifetime-extended temporary construction contexts.Artem Dergachev2018-06-281-8/+1
| | | | | | | | | | | | | | When a temporary object is materialized and through that obtain lifetime that is longer than the duration of the full-expression, it does not require a temporary object destructor; it will be destroyed in a different manner. Therefore it's not necessary to include CXXBindTemporaryExpr into the construction context for such temporary in the CFG only to make clients throw it away. Differential Revision: https://reviews.llvm.org/D47667 llvm-svn: 335798
* [analyzer] Re-enable lifetime extension for temporaries without destructors.Artem Dergachev2018-06-281-9/+7
| | | | | | | | | | | | | | | | When an object's class provides no destructor, it's less important to materialize that object properly because we don't have to model the destructor correctly, so previously we skipped the support for these syntax patterns. Additionally, fix support for construction contexts of "static temporaries" (temporaries that are lifetime-extended by static references) because it turned out that we only had tests for them without destructors, which caused us to regress when we re-introduced the construction context for such temporaries. Differential Revision: https://reviews.llvm.org/D47658 llvm-svn: 335796
* [CFG] [analyzer] Add construction contexts that explain pre-C++17 copy elision.Artem Dergachev2018-06-283-1/+12
| | | | | | | | | | | | | | | | Before C++17 copy elision was optional, even if the elidable copy/move constructor had arbitrary side effects. The elidable constructor is present in the AST, but marked as elidable. In these cases CFG now contains additional information that allows its clients to figure out if a temporary object is only being constructed so that to pass it to an elidable constructor. If so, it includes a reference to the elidable constructor's construction context, so that the client could elide the elidable constructor and construct the object directly at its final destination. Differential Revision: https://reviews.llvm.org/D47616 llvm-svn: 335795
* Revert "[Analyzer] Moved RangeConstraintManager to header. NFC."Mikhail R. Gadelha2018-06-271-0/+83
| | | | | | | | This broke a number of bots. This reverts commit 5e1a89912d37a21c3b49ccf30600d7f498dffa9c. llvm-svn: 335752
* [Analyzer] Moved RangeConstraintManager to header. NFC.Mikhail R. Gadelha2018-06-271-83/+0
| | | | | | | | | | | | | | Summary: While at it, added a dump method to RangeSet. Reviewers: george.karpenkov, NoQ Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D48561 llvm-svn: 335726
* [analyzer] [NFC] A convenient getter for getting a current stack frameGeorge Karpenkov2018-06-2712-50/+47
| | | | | | Differential Revision: https://reviews.llvm.org/D44756 llvm-svn: 335701
* [analyzer] Minor cleanups for BugReporter, expose a getter for AnalyzerOptions.George Karpenkov2018-06-261-10/+4
| | | | llvm-svn: 335683
* [analyzer] Do not run visitors until the fixpoint, run only once.George Karpenkov2018-06-262-295/+331
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In the current implementation, we run visitors until the fixed point is reached. That is, if a visitor adds another visitor, the currently processed path is destroyed, all diagnostics is discarded, and it is regenerated again, until it's no longer modified. This pattern has a few negative implications: - This loop does not even guarantee to terminate. E.g. just imagine two visitors bouncing a diagnostics around. - Performance-wise, e.g. for sqlite3 all visitors are being re-run at least 10 times for some bugs. We have already seen a few reports where it leads to timeouts. - If we want to add more computationally intense visitors, this will become worse. - From architectural standpoint, the current layout requires copying visitors, which is conceptually wrong, and can be annoying (e.g. no unique_ptr on visitors allowed). The proposed change is a much simpler architecture: the outer loop processes nodes upwards, and whenever the visitor is added it only processes current nodes and above, thus guaranteeing termination. Differential Revision: https://reviews.llvm.org/D47856 llvm-svn: 335666
* [analyzer] Track null and undef values through expressions with cleanups.Artem Dergachev2018-06-251-0/+2
| | | | | | | | | | | | | | | | | ExprWithCleanups wraps full-expressions that require temporary destructors and highlights the moment of time in which these destructors need to be called (i.e., "at the end of the full-expression..."). Such expressions don't necessarily return an object; they may return anything, including a null or undefined value. When the analyzer tries to understand where the null or undefined value came from in order to present better diagnostics to the user, it will now skip any ExprWithCleanups it encounters and look into the expression itself. Differential Revision: https://reviews.llvm.org/D48204 llvm-svn: 335559
* [analyzer] Fix invalidation on C++ const methods with arrow syntax.Artem Dergachev2018-06-251-2/+7
| | | | | | | | | | | | | | | | | | Conservative evaluation of a C++ method call would invalidate the object, as long as the method is not const or the object has mutable fields. When checking for mutable fields, we need to scan the type of the object on which the method is called, which may be more specific than the type of the object on which the method is defined, hence we look up the type from the this-argument expression. If arrow syntax or implicit-this syntax is used, this-argument expression has pointer type, not record type, and lookup accidentally failed for that reason. Obtain object type correctly. Differential Revision: https://reviews.llvm.org/D48460 llvm-svn: 335555
* [Fixed Point Arithmetic] Fixed Point Precision Bits and Fixed Point LiteralsLeonard Chan2018-06-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This diff includes the logic for setting the precision bits for each primary fixed point type in the target info and logic for initializing a fixed point literal. Fixed point literals are declared using the suffixes ``` hr: short _Fract uhr: unsigned short _Fract r: _Fract ur: unsigned _Fract lr: long _Fract ulr: unsigned long _Fract hk: short _Accum uhk: unsigned short _Accum k: _Accum uk: unsigned _Accum ``` Errors are also thrown for illegal literal values ``` unsigned short _Accum u_short_accum = 256.0uhk; // expected-error{{the integral part of this literal is too large for this unsigned _Accum type}} ``` Differential Revision: https://reviews.llvm.org/D46915 llvm-svn: 335148
* [analyzer] Optimize constraint generation when the range is a concrete valueMikhail R. Gadelha2018-06-201-52/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If a constraint is something like: ``` $0 = [1,1] ``` it'll now be created as: ``` assert($0 == 1) ``` instead of: ``` assert($0 >= 1 && $0 <= 1) ``` In general, ~3% speedup when solving per query in my machine. Biggest improvement was when verifying sqlite3, total time went down from 3000s to 2200s. I couldn't create a test for this as there is no way to dump the formula yet. D48221 adds a method to dump the formula but there is no way to do it from the command line. Also, a test that prints the formula will most likely fail in the future, as different solvers print the formula in different formats. Reviewers: NoQ, george.karpenkov, ddcc Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D48227 llvm-svn: 335116
* [analyzer] Remove accidentally committed lines.George Karpenkov2018-06-181-4/+1
| | | | llvm-svn: 334965
* [analyzer] Add method to the generic SMT API to dump the SMT formulaMikhail R. Gadelha2018-06-161-0/+7
| | | | | | | | | | | | | | | | | | | Summary: New method dump the SMT formula and the Z3 implementation. There is no test because I only used it for debugging. However, if requested, I can add an option to the static analyzer to dump the formula (whole program? per path?), maybe something like the trimmed graph but for SMT formulas. Reviewers: NoQ, george.karpenkov, ddcc Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D48221 llvm-svn: 334891
* [analyzer] Re-enable C++17-specific RVO construction contexts.Artem Dergachev2018-06-141-16/+6
| | | | | | | | | | | | | | | | | | | Not contexts themselves, but rather support for them in the analyzer. Such construction contexts appear when C++17 mandatory copy elision occurs while returning an object from a function, and presence of a destructor causes a CXXBindTemporaryExpr to appear in the AST. Additionally, such construction contexts may be chained, because a return-value construction context doesn't really explain where the object is being returned into, but only points to the parent stack frame, where the object may be consumed by literally anything including another return statement. This behavior is now modeled correctly by the analyzer as long as the object is not returned beyond the boundaries of the analysis. Differential Revision: https://reviews.llvm.org/D47405 llvm-svn: 334684
* [analyzer] Re-enable C++17-specific variable and member construction contexts.Artem Dergachev2018-06-141-3/+3
| | | | | | | | | | | | | | Not contexts themselves, but rather support for them in the analyzer. Such construction contexts appear when C++17 mandatory copy elision occurs during initialization, and presence of a destructor causes a CXXBindTemporaryExpr to appear in the AST. Similar C++17-specific constructors for return values are still to be supported. Differential Revision: https://reviews.llvm.org/D47351 llvm-svn: 334683
* [analyzer] Track class member initializer constructors path-sensitively.Artem Dergachev2018-06-142-60/+107
| | | | | | | | | | | | | | | The reasoning behind this change is similar to the previous commit, r334681. Because members are already in scope when construction occurs, we are not suffering from liveness problems, but we still want to figure out if the object was constructed with construction context, because in this case we'll be able to avoid trivial copy, which we don't always model perfectly. It'd also have more importance when copy elision is implemented. This also gets rid of the old CFG look-behind mechanism. Differential Revision: https://reviews.llvm.org/D47350 llvm-svn: 334682
* [analyzer] pr37270: Track constructor target region, even if just a variable.Artem Dergachev2018-06-143-44/+9
| | | | | | | | | | | | | | | | | | | | | | The very idea of construction context implies that first the object is constructed, and then later, in a separate moment of time, the constructed object goes into scope, i.e. becomes "live". Most construction contexts require path-sensitive tracking of the constructed object region in order to compute the outer expressions accordingly before the object becomes live. Semantics of simple variable construction contexts don't immediately require that such tracking happens in path-sensitive manner, but shortcomings of the analyzer force us to track it path-sensitively as well. Namely, whether construction context was available at all during construction is a path-sensitive information. Additionally, path-sensitive tracking takes care of our liveness problems that kick in as the temporal gap between construction and going-into-scope becomes larger (eg., due to copy elision). Differential Revision: https://reviews.llvm.org/D47305 llvm-svn: 334681
* [analyzer] NFC: Merge code for finding and tracking construction target.Artem Dergachev2018-06-143-128/+95
| | | | | | | | | | | | | | When analyzing C++ code, a common operation in the analyzer is to discover target region for object construction by looking at CFG metadata ("construction contexts"), and then track the region path-sensitively until object construction is resolved, where the amount of information, again, depends on construction context. Scan construction context only once for both purposes. Differential Revision: https://reviews.llvm.org/D47304 llvm-svn: 334678
* [analyzer] Fix offset overflow check in MemRegionGeorge Karpenkov2018-06-131-42/+8
| | | | | | | | | rdar://39593879 https://bugs.llvm.org/show_bug.cgi?id=37142 Differential Revision: https://reviews.llvm.org/D48139 llvm-svn: 334636
* Remove extraneous semicolon.Bill Wendling2018-06-131-1/+1
| | | | llvm-svn: 334573
* [analyzer] Do not crash in the visitor when the function is given more ↵George Karpenkov2018-06-121-1/+1
| | | | | | | | | | arguments than it has parameters rdar://40335545 Differential Revision: https://reviews.llvm.org/D48107 llvm-svn: 334560
* [analyzer] Ensure that loop widening does not invalidate referencesMatthew Voss2018-06-121-0/+19
| | | | | | | | | | Loop widening can invalidate a reference. If the analyzer attempts to visit the destructor to a non-existent reference, it will crash. This patch ensures that the reference is preserved. https://reviews.llvm.org/D47044 llvm-svn: 334554
* [analyzer] [NFC] Remove "removeInvalidation" from visitor APIGeorge Karpenkov2018-06-121-2/+3
| | | | | | | | | | | removeInvalidation is a very problematic API, as it makes suppression order-dependent. Moreover, it was used only once, and could be rewritten in a much cleaner way. Differential Revision: https://reviews.llvm.org/D48045 llvm-svn: 334542
* [analyzer] [NFC] Move ::dump methods from BugReporter.cpp to PathDiagnostics.cppGeorge Karpenkov2018-06-122-104/+100
| | | | | | | | | | BugReporter.cpp is already severely overloaded, and those dump methods are on PathDiagnostics and should belong in the corresponding implementation file. Differential Revision: https://reviews.llvm.org/D48035 llvm-svn: 334541
* [analyzer] [NFC] Remove most usages of getEndPathGeorge Karpenkov2018-06-122-18/+23
| | | | | | | | | | | | | | | getEndPath is a problematic API, because it's not clear when it's called (hint: not always at the end of the path), it crashes at runtime with more than one non-nullptr returning implementation, and diagnostics internal depend on it being called at some exact place. However, most visitors don't actually need that: all they want is a function consistently called after all nodes are traversed, to perform finalization and to decide whether invalidation is needed. Differential Revision: https://reviews.llvm.org/D48042 llvm-svn: 334540
* [analyzer] [NFC] Now let's have only one place for diagnostics generationGeorge Karpenkov2018-06-121-43/+15
| | | | | | Differential Revision: https://reviews.llvm.org/D47808 llvm-svn: 334526
* [analyzer] [NFC] Unify Minimal and Extensive diagnostics.George Karpenkov2018-06-121-286/+243
| | | | | | | | | | Once we removed AlternateExtensive, I've looked closer into the difference between Minimal and Extensive, and turns out, the difference was not that large. Differential Revision: https://reviews.llvm.org/D47756 llvm-svn: 334525
* [analyzer] [NFC] Remove unused Extensive diagnostic setting,George Karpenkov2018-06-121-565/+10
| | | | | | | | | | | | | | Rename AlternateExtensive to Extensive. In 2013, five years ago, we have switched to AlternateExtensive diagnostics by default, and Extensive was available under unused, undocumented flag. This change remove the flag, renames the Alternate diagnostic to Extensive (as it's no longer Alternate), and ports the test. Differential Revision: https://reviews.llvm.org/D47670 llvm-svn: 334524
* [FileSystem] Split up the OpenFlags enumeration.Zachary Turner2018-06-071-4/+2
| | | | | | | | | | | | | | | | | This breaks the OpenFlags enumeration into two separate enumerations: OpenFlags and CreationDisposition. The first controls the behavior of the API depending on whether or not the target file already exists, and is not a flags-based enum. The second controls more flags-like values. This yields a more easy to understand API, while also allowing flags to be passed to the openForRead api, where most of the values didn't make sense before. This also makes the apis more testable as it becomes easy to enumerate all the configurations which make sense, so I've added many new tests to exercise all the different values. llvm-svn: 334221
* [Analyzer] Fix Z3ConstraintManager crash (PR37646)Vlad Tsyrklevich2018-06-061-2/+4
| | | | | | | | | | | | | | | | Summary: Fix another Z3ConstraintManager crash, use fixAPSInt() to extend a boolean APSInt. Reviewers: george.karpenkov, NoQ, ddcc Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin, cfe-commits Differential Revision: https://reviews.llvm.org/D47617 llvm-svn: 334065
* [analyzer] Re-enable constructors when lifetime extension through fields occurs.Artem Dergachev2018-06-042-20/+6
| | | | | | | | | | | | | | | | Temporary object constructor inlining was disabled in r326240 for code like const int &x = A().x; because automatic destructor for the lifetime-extended object A() was not working correctly in CFG. CFG was fixed in r333941, so inlining can be re-enabled. CFG for lifetime extension through aggregates still needs to be fixed. Differential Revision: https://reviews.llvm.org/D44239 llvm-svn: 333946
* [analyzer] False positive refutation with Z3Mikhail R. Gadelha2018-06-043-1/+56
| | | | | | | | | | | | | | Summary: This is a prototype of a bug reporter visitor that invalidates bug reports by re-checking constraints of certain states on the bug path using the Z3 constraint manager backend. The functionality is available under the `crosscheck-with-z3` analyzer config flag. Reviewers: george.karpenkov, NoQ, dcoughlin, rnkovacs Reviewed By: george.karpenkov Subscribers: rnkovacs, NoQ, george.karpenkov, dcoughlin, xbolva00, ddcc, mikhail.ramalho, MTC, fhahn, whisperity, baloghadamsoftware, szepet, a.sidorin, gsd, dkrupp, xazax.hun, cfe-commits Differential Revision: https://reviews.llvm.org/D45517 llvm-svn: 333903
* Created a tiny SMT interface and make Z3ConstraintManager implement itMikhail R. Gadelha2018-06-041-3/+58
| | | | | | | | | | | | | | | | | | | Summary: This patch implements a simple SMTConstraintManager API, and requires the implementation of two methods for now: `addRangeConstraints` and `isModelFeasible`. Update Z3ConstraintManager to inherit it and implement required methods. I also moved the method to dump the SMT formula from D45517 to this patch. This patch was created based on the reviews from D47640. Reviewers: george.karpenkov, NoQ, ddcc, dcoughlin Reviewed By: george.karpenkov Differential Revision: https://reviews.llvm.org/D47689 llvm-svn: 333899
* Moved RangedConstraintManager header to the StaticAnalyser include dirMikhail R. Gadelha2018-06-043-216/+2
| | | | | | | | | | | | | | | Summary: Moved `RangedConstraintManager` header from `lib/StaticAnalyzer/Core/` to `clang/StaticAnalyzer/Core/PathSensitive/`. No changes to the code. Reviewers: NoQ, george.karpenkov, dcoughlin Reviewed By: george.karpenkov Subscribers: NoQ, george.karpenkov, dcoughlin, ddcc Differential Revision: https://reviews.llvm.org/D47640 llvm-svn: 333862
* [analyzer] NFC: Track all constructed objects in a single state trait.Artem Dergachev2018-06-013-277/+133
| | | | | | | | | | | | | | | ExprEngine already maintains three internal program state traits to track path-sensitive information related to object construction: pointer returned by operator new, and pointer to temporary object for two different purposes - for destruction and for lifetime extension. We'll need to add 2-3 more in a few follow-up commits. Merge these traits into one because they all essentially serve one purpose and work similarly. Differential Revision: https://reviews.llvm.org/D47303 llvm-svn: 333719
* [analyzer] fix bug with 1-bit APSInt types in Z3ConstraintManagerDominic Chen2018-05-311-22/+50
| | | | | | | | | | | | Summary: Clang does not have a corresponding QualType for a 1-bit APSInt, so use the BoolTy and extend the APSInt. Split from D35450. Fixes PR37622. Reviewers: george.karpenkov, NoQ Subscribers: mikhail.ramalho, xazax.hun, szepet, rnkovacs, cfe-commits, a.sidorin Differential Revision: https://reviews.llvm.org/D47603 llvm-svn: 333704
* [analyzer] Improve performance of the SVal simplification mechanism further.Artem Dergachev2018-05-311-6/+31
| | | | | | | | | | | Memoize simplification so that we didn't need to simplify the same symbolic expression twice within the same program state. Gives ~25% performance boost on the artificial test in test/Analysis/hangs.c. Differential Revision: https://reviews.llvm.org/D47402 llvm-svn: 333671
* [analyzer] Improve performance of the SVal simplification mechanism.Artem Dergachev2018-05-311-5/+19
| | | | | | | | | | | | When neither LHS nor RHS of a binary operator expression can be simplified, return the original expression instead of re-evaluating the binary operator. Such re-evaluation was causing recusrive re-simplification which caused the algorithmic complexity to explode. Differential Revision: https://reviews.llvm.org/D47155 llvm-svn: 333670
* [analyzer] const init: handle non-explicit cases more accuratelyRafael Stahl2018-05-291-5/+18
| | | | | | | | | | | | | | Summary: If the access is out of bounds, return UndefinedVal. If it is missing an explicit init, return the implicit zero value it must have. Reviewers: NoQ, xazax.hun, george.karpenkov Reviewed By: NoQ Subscribers: szepet, rnkovacs, a.sidorin, cfe-commits Differential Revision: https://reviews.llvm.org/D46823 llvm-svn: 333417
* [analyzer] Added template argument lists to the Pathdiagnostic outputKristof Umann2018-05-251-2/+50
| | | | | | | | | | | Because template parameter lists were not displayed in the plist output, it was difficult to decide in some cases whether a given checker found a true or a false positive. This patch aims to correct this. Differential Revision: https://reviews.llvm.org/D46933 llvm-svn: 333275
* [analyzer] Move RangeSet related declarations into the ↵Mikhail R. Gadelha2018-05-242-236/+256
| | | | | | | | | | | | | | | | | | RangedConstraintManager header. Summary: I could also move `RangedConstraintManager.h` under `include/` if you agree as it seems slightly out of place under `lib/`. Patch by Réka Kovács Reviewers: NoQ, george.karpenkov, dcoughlin, rnkovacs Reviewed By: NoQ Subscribers: mikhail.ramalho, whisperity, xazax.hun, baloghadamsoftware, szepet, a.sidorin, dkrupp, cfe-commits Differential Revision: https://reviews.llvm.org/D45920 llvm-svn: 333179
* [clang] Update uses of DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-152-6/+6
| | | | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM Explicitly avoided changing the strings in the clang-format tests. Differential Revision: https://reviews.llvm.org/D44975 llvm-svn: 332350
OpenPOWER on IntegriCloud