summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Core
Commit message (Collapse)AuthorAgeFilesLines
...
* [analyzer] Fix keyboard navigation for .msgNote eventsGeorge Karpenkov2018-08-111-1/+2
| | | | | | | | Does not go to msgNote's. Differential Revision: https://reviews.llvm.org/D50595 llvm-svn: 339493
* [analyzer] Fix tracking expressions through negation operatorGeorge Karpenkov2018-08-101-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D50537 llvm-svn: 339476
* Invalidate static locals when escaping lambdasGeorge Karpenkov2018-08-101-0/+27
| | | | | | | | | | Lambdas can affect static locals even without an explicit capture. rdar://39537031 Differential Revision: https://reviews.llvm.org/D50368 llvm-svn: 339459
* Port getLocEnd -> getEndLocStephen Kelly2018-08-093-5/+5
| | | | | | | | | | Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50351 llvm-svn: 339386
* Port getLocStart -> getBeginLocStephen Kelly2018-08-097-36/+37
| | | | | | | | | | Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
* Port getStartLoc -> getBeginLocStephen Kelly2018-08-091-1/+1
| | | | | | | | | | Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50349 llvm-svn: 339384
* [analyzer] Avoid querying this-pointers for static-methods.Matt Davis2018-08-071-2/+4
| | | | | | | | | | | | | | | | | | | Summary: The loop-widening code processes c++ methods looking for `this` pointers. In the case of static methods (which do not have `this` pointers), an assertion was triggering. This patch avoids trying to process `this` pointers for static methods, and thus avoids triggering the assertion . Reviewers: dcoughlin, george.karpenkov, NoQ Reviewed By: NoQ Subscribers: NoQ, xazax.hun, szepet, a.sidorin, mikhail.ramalho, cfe-commits Differential Revision: https://reviews.llvm.org/D50408 llvm-svn: 339201
* [analyzer] Add ASTContext to CheckerManagerGeorge Karpenkov2018-08-061-22/+22
| | | | | | | | | Some checkers require ASTContext. Having it in the constructor saves a lot of boilerplate of having to pass it around. Differential Revision: https://reviews.llvm.org/D50111 llvm-svn: 339079
* [analyzer] Do not crash in NoStoreFuncVisitor notes if an unexpected region ↵George Karpenkov2018-08-031-7/+14
| | | | | | | | is found. Just do not generate the note at all in that case. llvm-svn: 338935
* [analyzer] Obtain a ReturnStmt from a CFGAutomaticObjDtor.Reka Kovacs2018-08-021-1/+5
| | | | | | | | | | | The CoreEngine only gives us a ReturnStmt if the last element in the CFGBlock is a CFGStmt, otherwise the ReturnStmt is nullptr. This patch adds support for the case when the last element is a CFGAutomaticObjDtor, by returning its TriggerStmt as a ReturnStmt. Differential Revision: https://reviews.llvm.org/D49811 llvm-svn: 338777
* [analyzer] Make RegionVector use const referenceFangrui Song2018-08-021-10/+7
| | | | llvm-svn: 338732
* [analyzer] Extend NoStoreFuncVisitor to follow fields.George Karpenkov2018-08-021-126/+212
| | | | | | | | rdar://39701823 Differential Revision: https://reviews.llvm.org/D49901 llvm-svn: 338667
* Add missing semicolon.Simon Pilgrim2018-08-011-1/+1
| | | | llvm-svn: 338510
* Replace 'FALL-THROUGH' comment with LLVM_FALLTHROUGH to silence warning. NFCI.Simon Pilgrim2018-08-011-1/+1
| | | | llvm-svn: 338508
* [analyzer] CallEvent: Add helper methods for obtaining the callee stack frame.Artem Dergachev2018-08-011-0/+63
| | | | | | | | | | | | Newly added methods allow reasoning about the stack frame of the call (as opposed to the stack frame on which the call was made, which was always available) - obtain the stack frame context, obtain parameter regions - even if the call is not going to be (or was not) inlined, i.e. even if the analysis has never actually entered the stack frame. Differential Revision: https://reviews.llvm.org/D49715 llvm-svn: 338474
* [analyzer] Fix eliding the same destructor twice due to buggy default arguments.Artem Dergachev2018-07-311-1/+2
| | | | | | | | | | | Because of incomplete support for CXXDefaultArgExpr, we cannot yet commit to asserting that the same destructor won't be elided twice. Suppress the assertion failure for now. Proper support is still an open problem. Differential Revision: https://reviews.llvm.org/D49213 llvm-svn: 338441
* [CFG] [analyzer] NFC: Enumerate construction context layer kinds.Artem Dergachev2018-07-311-93/+48
| | | | | | | | | | | | | | This is a refactoring patch; no functional change intended. The common part of ConstructionContextLayer and ConstructedObjectKey is factored out into a new structure, ConstructionContextItem. Various sub-kinds of ConstructionContextItem are enumerated in order to provide richer information about construction contexts. Differential Revision: https://reviews.llvm.org/D49210. llvm-svn: 338439
* [CFG] [analyzer] Implement function argument construction contexts.Artem Dergachev2018-07-311-11/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | In r330377 and r338425 we have already identified what constitutes function argument constructors and added stubs in order to prevent confusing them with other temporary object constructors. Now we implement a ConstructionContext sub-class to carry all the necessary information about the construction site, namely call expression and argument index. On the analyzer side, the patch interacts with the recently implemented pre-C++17 copy elision support in an interesting manner. If on the CFG side we didn't find a construction context for the elidable constructor, we build the CFG as if the elidable constructor is not elided, and the non-elided constructor within it is a simple temporary. But the same problem may occur in the analyzer: if the elidable constructor has a construction context but the analyzer doesn't implement such context yet, the analyzer should also try to skip copy elision and still inline the non-elided temporary constructor. This was implemented by adding a "roll back" mechanism: when elision fails, roll back the changes and proceed as if it's a simple temporary. The approach is wonky, but i'm fine with that as long as it's merely a defensive mechanism that should eventually go away once all construction contexts become supported. Differential Revision: https://reviews.llvm.org/D48681. llvm-svn: 338436
* [analyzer] Reuse some code in simplifySVal().Artem Dergachev2018-07-311-21/+22
| | | | | | | | No functional change intended. Differential Revision: https://reviews.llvm.org/D49826 llvm-svn: 338422
* [analyzer] Don't try to simplify mixed Loc/NonLoc expressions.Artem Dergachev2018-07-311-0/+11
| | | | | | | | | | | | | | | | | | This fix is similar to r337769 and addresses a regression caused by r337167. When an operation between a nonloc::LocAsInteger and a non-pointer symbol is performed, the LocAsInteger-specific part of information is lost. When the non-pointer symbol is collapsing into a constant, we cannot easily re-evaluate the result, because we need to recover the missing LocAsInteger-specific information (eg., integer type, or the very fact that this pointer was at some point converted to an integer). Add one more defensive check to prevent crashes on trying to simplify a SymSymExpr with different Loc-ness of operands. Differential Revision: llvm-svn: 338420
* [analyzer] [NFC] Simplify some visitors by giving a convenient getter from ↵George Karpenkov2018-07-302-22/+20
| | | | | | | | state to analysis manager Differential Revision: https://reviews.llvm.org/D49772 llvm-svn: 338315
* Remove trailing spaceFangrui Song2018-07-305-9/+9
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [analyzer] Extend NoStoreFuncVisitor to insert a note on IVarsGeorge Karpenkov2018-07-271-13/+50
| | | | | | | | | | | | | | The note is added in the following situation: - We are throwing a nullability-related warning on an IVar - The path goes through a method which *could have* (syntactically determined) written into that IVar, but did not rdar://42444460 Differential Revision: https://reviews.llvm.org/D49689 llvm-svn: 338149
* [analyzer] Fixed method to get APSInt modelMikhail R. Gadelha2018-07-261-23/+18
| | | | | | | | | | | | | | | | | | | Summary: This patch replaces the current method of getting an `APSInt` from Z3's model by calling generic API method `getBitvector` instead of `Z3_get_numeral_uint64`. By calling `getBitvector`, there's no need to handle bitvectors with bit width == 128 separately. And, as a bonus, clang now compiles correctly with Z3 4.7.1. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49818 llvm-svn: 338020
* [analyzer] Update SMT API documentation and methodsMikhail R. Gadelha2018-07-252-24/+19
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Update the documentation of all the classes introduced with the new generic SMT API, most of them were referencing Z3 and how previous operations were being done (like including the context as parameter in a few methods). Renamed the following methods, so it's clear that the operate on bitvectors: *`mkSignExt` -> `mkBVSignExt` *`mkZeroExt` -> `mkBVZeroExt` *`mkExtract` -> `mkBVExtract` *`mkConcat` -> `mkBVConcat` Removed the unecessary methods: * `getDataExpr`: it was an one line method that called `fromData` * `mkBitvector(const llvm::APSInt Int)`: it was not being used anywhere Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49799 llvm-svn: 337954
* [analyzer] Use the macro REGISTER_TRAIT_WITH_PROGRAMSTATE in the Z3 backendMikhail R. Gadelha2018-07-251-22/+7
| | | | | | | | | | | | | | | | | Summary: The macro was manually expanded in the Z3 backend and this patch adds it back. Adding the expanded code is dangerous as the macro may change in the future and the expanded code might be left outdated. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49769 llvm-svn: 337923
* [analyzer] Removed API used by the Refutation Manager from ↵Mikhail R. Gadelha2018-07-253-58/+43
| | | | | | | | | | | | | | | | | | | | | | | SMTConstraintManager and replace by proper calls to SMTSolver Summary: Third patch in the refactoring series, to decouple the SMT Solver from the Refutation Manager (1st: D49668, 2nd: D49767). The refutation API in the `SMTConstraintManager` was a hack to allow us to create an SMT solver and verify the constraints; it was conceptually wrong from the start. Now, we don't actually need to use the `SMTConstraintManager` and can create an SMT object directly, add the constraints and check them. While updating the Falsification visitor, I inlined the two functions that were used to collect the constraints and add them to the solver. As a result of this patch, we could move the SMT API elsewhere and as it's not really dependent on the CSA anymore. Maybe we can create a new dir (utils/smt) for Z3 and future solvers? Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49768 llvm-svn: 337922
* [analyzer] Moved code from SMTConstraintManager to SMTSolverMikhail R. Gadelha2018-07-251-298/+24
| | | | | | | | | | | | | | | | | Summary: This is the second part of D49668, and moves all the code that's not specific to a ConstraintManager to SMTSolver. No functional change intended. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49767 llvm-svn: 337921
* [analyzer] Try to minimize the number of equivalent bug reports evaluated by ↵Mikhail R. Gadelha2018-07-251-4/+17
| | | | | | | | | | | | | | | | | | | | | | | the refutation manager Summary: This patch changes how the SMT bug refutation runs in an equivalent bug report class. Now, all other visitor are executed until they find a valid bug or mark all bugs as invalid. When the one valid bug is found (and crosscheck is enabled), the SMT refutation checks the satisfiability of this single bug. If the bug is still valid after checking with Z3, it is returned and a bug report is created. If the bug is found to be invalid, the next bug report in the equivalent class goes through the same process, until we find a valid bug or all bugs are marked as invalid. Massive speedups when verifying redis/src/rax.c, from 1500s to 10s. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49693 llvm-svn: 337920
* [analyzer] Moved non solver specific code from Z3ConstraintManager to ↵Mikhail R. Gadelha2018-07-253-765/+552
| | | | | | | | | | | | | | | | | | | | | | | SMTConstraintManager Summary: This patch moves a lot of code from `Z3ConstraintManager` to `SMTConstraintManager`, leaving only the necessary: * `canReasonAbout` which returns if a Solver can handle a given `SVal` (should be moved to `SMTSolver` in the future). * `removeDeadBindings`, `assumeExpr` and `print`: methods that need to use `ConstraintZ3Ty`, can probably be moved to `SMTConstraintManager` in the future. The patch creates a new file, `SMTConstraintManager.cpp` with the moved code. Conceptually, this is move in the right direction and needs further improvements: `SMTConstraintManager` still does a lot of things that are not required by a `ConstraintManager`. We ought to move the unrelated to `SMTSolver` and remove everything that's not related to a `ConstraintManager`. In particular, we could remove `addRangeConstraints` and `isModelFeasible`, and make the refutation manager create an Z3Solver directly. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: mgorny, xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49668 llvm-svn: 337919
* [analyzer] Implemented SMT generic APIMikhail R. Gadelha2018-07-251-545/+569
| | | | | | | | | | | | | | | | | Summary: Created new SMT generic API. Small changes to `Z3ConstraintManager` because of the new generic objects (`SMTSort` and `SMTExpr`) returned by `SMTSolver`. Reviewers: george.karpenkov, NoQ Reviewed By: george.karpenkov Subscribers: mgorny, xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49495 llvm-svn: 337918
* [analyzer] Create generic SMT Expr classMikhail R. Gadelha2018-07-251-53/+44
| | | | | | | | | | | | | | | | | Summary: New base class for all future SMT Exprs. No major changes except moving `areEquivalent` and `getFloatSemantics` outside of `Z3Expr` to keep the class minimal. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49551 llvm-svn: 337917
* [analyzer] Create generic SMT Sort ClassMikhail R. Gadelha2018-07-251-25/+29
| | | | | | | | | | | | | | | | | Summary: New base class for all future SMT sorts. The only change is that the class implements methods `isBooleanSort()`, `isBitvectorSort()` and `isFloatSort()` so it doesn't rely on `Z3`'s enum. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49550 llvm-svn: 337916
* [analyzer] Moved static Context to class memberMikhail R. Gadelha2018-07-251-450/+471
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Although it is a big patch, the changes are simple: 1. There is one `Z3_Context` now, member of the `SMTConstraintManager` class. 2. `Z3Expr`, `Z3Sort`, `Z3Model` and `Z3Solver` are constructed with a reference to the `Z3_Context` in `SMTConstraintManager`. 3. All static functions are now members of `Z3Solver`, e.g, the `SMTConstraintManager` now calls `Solver.fromBoolean(false)` instead of `Z3Expr::fromBoolean(false)`. Most of the patch only move stuff around except: 1. New method `Z3Sort MkSort(const QualType &Ty, unsigned BitWidth)`, that creates a sort based on the `QualType` and its width. Used to simplify the `fromData` method. Unfortunate consequence of this patch: 1. `getInterpretation` was moved from `Z3Model` class to `Z3Solver`, because it needs to create a `Z3Sort` before returning the interpretation. This can be fixed by changing both `toAPFloat` and `toAPSInt` by removing the dependency of `Z3Sort` (it's only used to check which Sort was created and to retrieve the type width). Reviewers: NoQ, george.karpenkov, ddcc Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49236 llvm-svn: 337915
* [analyzer] Create generic SMT Context classMikhail R. Gadelha2018-07-251-6/+10
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch creates `SMTContext` which will wrap a specific SMT context, through `SMTSolverContext`. The templated `SMTSolverContext` class it's a simple wrapper around a SMT specific context (currently only used in the Z3 backend), while `Z3Context` inherits `SMTSolverContext<Z3_context>` and implements solver specific operations like initialization and destruction of the context. This separation was done because: 1. We might want to keep one single context, shared across different `SMTConstraintManager`s. It can be achieved by constructing a `SMTContext`, through a function like `CreateSMTContext(Z3)`, `CreateSMTContext(BOOLECTOR)`, etc. The rest of the CSA only need to know about `SMTContext`, so maybe it's a good idea moving `SMTSolverContext` to a separate header in the future. 2. Any generic SMT operation will only require one `SMTSolverContext`object, which can access the specific context by calling `getContext()`. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49233 llvm-svn: 337914
* Revert "[analyzer] Extend NoStoreFuncVisitor to insert a note on IVars"George Karpenkov2018-07-241-50/+13
| | | | | | | This reverts commit a9e21bd727112cd69eabc1af648c5da6b773d06e. Reverted because the dependency has not landed yet. llvm-svn: 337866
* [analyzer] Extend NoStoreFuncVisitor to insert a note on IVarsGeorge Karpenkov2018-07-241-13/+50
| | | | | | | | | | | | | | The note is added in the following situation: - We are throwing a nullability-related warning on an IVar - The path goes through a method which *could have* (syntactically determined) written into that IVar, but did not rdar://42444460 Differential Revision: https://reviews.llvm.org/D49689 llvm-svn: 337864
* [analyzer] pr38273: Legalize Loc<>NonLoc comparison symbols.Artem Dergachev2018-07-231-2/+4
| | | | | | | | | Remove an assertion in RangeConstraintManager that expects such symbols to never appear, while admitting that the constraint manager doesn't yet handle them. Differential Revision: https://reviews.llvm.org/D49703 llvm-svn: 337769
* [Analyzer] Quick Fix for exponential execution time when simpilifying ↵Adam Balogh2018-07-232-9/+12
| | | | | | | | | | | | | | | | | | complex additive expressions Patch https://reviews.llvm.org/rC329780 not only rearranges comparisons but also binary expressions. This latter behavior is not protected by the analyzer option. Hower, since no complexity threshold is enforced to the symbols this may result in exponential execution time if the expressions are too complex: https://bugs.llvm.org/show_bug.cgi?id=38208. For a quick fix we extended the analyzer option to also cover the additive cases. This is only a temporary fix, the final solution should be enforcing the complexity threshold to the symbols. Differential Revision: https://reviews.llvm.org/D49536 llvm-svn: 337678
* [analyzer] Memoize complexity of SymExprMikhail R. Gadelha2018-07-192-8/+1
| | | | | | | | | | | | | | | | | Summary: This patch introduces a new member to SymExpr, which stores the symbol complexity, avoiding recalculating it every time computeComplexity() is called. Also, increase the complexity of conjured Symbols by one, so it's clear that it has a greater complexity than its underlying symbols. Reviewers: NoQ, george.karpenkov Reviewed By: NoQ, george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49232 llvm-svn: 337472
* [analyzer] Remove a debug print that was accidentally left around.Artem Dergachev2018-07-181-1/+0
| | | | | | No functional change intended. llvm-svn: 337417
* [analyzer] Fix Z3 backend after D48205Mikhail R. Gadelha2018-07-171-30/+29
| | | | | | | | | | | | | | | | | Summary: An assertion was added in D48205 to catch places where a `nonloc::SymbolVal` was wrapping a `loc` object. This patch fixes that in the Z3 backend by making the `SValBuilder` object accessible from inherited instances of `SimpleConstraintManager` and calling `SVB.makeSymbolVal(foo)` instead of `nonloc::SymbolVal(foo)`. Reviewers: NoQ, george.karpenkov Reviewed By: NoQ Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49430 llvm-svn: 337304
* [analyzer] pr37802: Fix symbolic-pointer-to-boolean casts during load.Artem Dergachev2018-07-171-1/+2
| | | | | | | | | The canonical representation of pointer &SymRegion{$x} casted to boolean is "$x != 0", not "$x". Assertion added in r337227 catches that. Differential Revision: https://reviews.llvm.org/D48232 llvm-svn: 337228
* [analyzer] Assert that nonloc::SymbolVal always wraps a non-Loc-type symbol.Artem Dergachev2018-07-171-1/+1
| | | | | | | | | | | | | | | In the current SVal hierarchy there are multiple ways of representing certain values but few are actually used and expected to be seen by the code. In particular, a value of a symbolic pointer is always represented by a loc::MemRegionVal that wraps a SymbolicRegion that wraps the pointer symbol and never by a nonloc::SymbolVal that wraps that symbol directly. Assert the aforementioned fact. Fix one minor violation of it. Differential Revision: https://reviews.llvm.org/D48205 llvm-svn: 337227
* [analyzer] Make checkEndFunction() give access to the return statement.Reka Kovacs2018-07-162-4/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D49387 llvm-svn: 337215
* [analyzer] Bugfix for an overly eager suppression for null pointer return ↵George Karpenkov2018-07-161-39/+60
| | | | | | | | | | | | | from macros. Only suppress those cases where the null which came from the macro is relevant to the bug, and was not overwritten in between. rdar://41497323 Differential Revision: https://reviews.llvm.org/D48856 llvm-svn: 337213
* [analyzer] Fix the Z3 backend always generating unsigned APSIntMikhail R. Gadelha2018-07-161-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In `toAPSInt`, the Z3 backend was not checking the variable `Int`'s type and was always generating unsigned `APSInt`s. This was found by accident when I removed: ``` llvm::APSInt ConvertedLHS, ConvertedRHS; QualType LTy, RTy; std::tie(ConvertedLHS, LTy) = fixAPSInt(*LHS); std::tie(ConvertedRHS, RTy) = fixAPSInt(*RHS); - doIntTypePromotion<llvm::APSInt, Z3ConstraintManager::castAPSInt>( - ConvertedLHS, LTy, ConvertedRHS, RTy); return BVF.evalAPSInt(BSE->getOpcode(), ConvertedLHS, ConvertedRHS); ``` And the `BasicValueFactory` started to complain about different `signedness`. Reviewers: george.karpenkov, NoQ, ddcc Reviewed By: ddcc Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49305 llvm-svn: 337169
* [analyzer] Fix constraint being dropped when analyzing a program without ↵Mikhail R. Gadelha2018-07-163-15/+14
| | | | | | | | | | | | | | | | | | | | | | | taint tracking enabled Summary: This patch removes the constraint dropping when taint tracking is disabled. It also voids the crash reported in D28953 by treating a SymSymExpr with non pointer symbols as an opaque expression. Updated the regressions and verifying the big projects now; I'll update here when they're done. Based on the discussion on the mailing list and the patches by @ddcc. Reviewers: george.karpenkov, NoQ, ddcc, baloghadamsoftware Reviewed By: george.karpenkov Subscribers: delcypher, llvm-commits, rnkovacs, xazax.hun, szepet, a.sidorin, ddcc Differential Revision: https://reviews.llvm.org/D48650 llvm-svn: 337167
* DR330: look through array types when forming the cv-decomposition of a type.Richard Smith2018-07-111-1/+5
| | | | | | | | | | This allows more qualification conversions, eg. conversion from 'int *(*)[]' -> 'const int *const (*)[]' is now permitted, along with all the consequences of that: more types are similar, more cases are permitted by const_cast, and conversely, fewer "casting away constness" cases are permitted by reinterpret_cast. llvm-svn: 336745
* [analyzer] Add option to set maximum symbol complexity thresholdMikhail R. Gadelha2018-07-102-1/+11
| | | | | | | | | | | | | | | | | | | Summary: This adds an option, max-symbol-complexity, so an user can set the maximum symbol complexity threshold. Note that the current behaviour is equivalent to max complexity = 0, when taint analysis is not enabled and tests show that in a number of tests, having complexity = 25 yields the same results as complexity = 10000. This patch was extracted and modified from Dominic Chen's patch, D35450. Reviewers: george.karpenkov, NoQ, ddcc Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49093 llvm-svn: 336671
OpenPOWER on IntegriCloud