- Mar 03, 2017
-
-
Dominic Chen authored
Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952. Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits Differential Revision: https://reviews.llvm.org/D30373 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@296895 91177308-0d34-0410-b5e6-96231b3b80d8
-
Dominic Chen authored
Revert "Reland 3: [analyzer] NFC: Update test infrastructure to support multiple constraint managers" This reverts commit ea36f140. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@296841 91177308-0d34-0410-b5e6-96231b3b80d8
-
Dominic Chen authored
Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952. Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits Differential Revision: https://reviews.llvm.org/D30373 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@296837 91177308-0d34-0410-b5e6-96231b3b80d8
-
- Mar 02, 2017
-
-
Dominic Chen authored
Revert "Reland 2: [analyzer] NFC: Update test infrastructure to support multiple constraint managers" This reverts commit f93343c0. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@296836 91177308-0d34-0410-b5e6-96231b3b80d8
-
Dominic Chen authored
Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952. Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits Differential Revision: https://reviews.llvm.org/D30373 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@296835 91177308-0d34-0410-b5e6-96231b3b80d8
-
- Feb 28, 2017
-
-
Dominic Chen authored
This reverts commit 1b28d0b1. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@296422 91177308-0d34-0410-b5e6-96231b3b80d8
-
Dominic Chen authored
Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952. Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits Differential Revision: https://reviews.llvm.org/D30373 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@296414 91177308-0d34-0410-b5e6-96231b3b80d8
-
- Feb 27, 2017
-
-
Dominic Chen authored
This reverts commit 8e7780b9. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@296317 91177308-0d34-0410-b5e6-96231b3b80d8
-
Dominic Chen authored
Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952. Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits Differential Revision: https://reviews.llvm.org/D30373 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@296312 91177308-0d34-0410-b5e6-96231b3b80d8
-
- Nov 08, 2013
-
-
Jordan Rose authored
This syntactic checker looks for expressions on both sides of comparison operators that are structurally the same. As a special case, the floating-point idiom "x != x" for "isnan(x)" is left alone. Currently this only checks comparison operators, but in the future we could extend this to include logical operators or chained if-conditionals. Checker by Per Viberg! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194236 91177308-0d34-0410-b5e6-96231b3b80d8
-
- Aug 29, 2013
-
-
Pavel Labath authored
Summary: RegionStoreManager had an optimization which replaces references to empty structs with UnknownVal. Unfortunately, this check didn't take into account possible field members in base classes. To address this, I changed this test to "is empty and has no base classes". I don't consider it worth the trouble to go through base classes and check if all of them are empty. Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1547 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189590 91177308-0d34-0410-b5e6-96231b3b80d8
-
- Oct 17, 2012
-
-
Jordan Rose authored
This actually looks through several kinds of expression, such as OpaqueValueExpr and ExprWithCleanups. The idea is that binding and lookup should be consistent, and so if the environment needs to be modified later, the code doing the modification will not have to manually look through these "transparent" expressions to find the real binding to change. This is necessary for proper updating of struct rvalues as described in the previous commit. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166121 91177308-0d34-0410-b5e6-96231b3b80d8
-
Jordan Rose authored
In C++, rvalues that need to have their address taken (for example, to be passed to a function by const reference) will be wrapped in a MaterializeTemporaryExpr, which lets CodeGen know to create a temporary region to store this value. However, MaterializeTemporaryExprs are /not/ created when a method is called on an rvalue struct, even though the 'this' pointer needs a valid value. CodeGen works around this by creating a temporary region anyway; now, so does the analyzer. The analyzer also does this when accessing a field of a struct rvalue. This is a little unfortunate, since the rest of the struct will soon be thrown away, but it does make things consistent with the rest of the analyzer. This allows us to bring back the assumption that all known 'this' values are Locs. This is a revised version of r164828-9, reverted in r164876-7. <rdar://problem/12137950> git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166120 91177308-0d34-0410-b5e6-96231b3b80d8
-
- Oct 01, 2012
-
-
Jordan Rose authored
This is related to but not blocked by <rdar://problem/12137950> ("Return-by-value structs do not have associated regions") This reverts r164875 / 3278d41e17749dbedb204a81ef373499f10251d7. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164952 91177308-0d34-0410-b5e6-96231b3b80d8
-
- Sep 29, 2012
-
-
Jordan Rose authored
This reverts commit 0006ba44. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164876 91177308-0d34-0410-b5e6-96231b3b80d8
-
Jordan Rose authored
This reverts commit 580cd17f. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164875 91177308-0d34-0410-b5e6-96231b3b80d8
-
- Sep 28, 2012
-
-
Jordan Rose authored
Previously the analyzer treated all inlined constructors like lvalues, setting the value of the CXXConstructExpr to the newly-constructed region. However, some CXXConstructExprs behave like rvalues -- in particular, the implicit copy constructor into a pass-by-value argument. In this case, we want only the /contents/ of a temporary object to be passed, so that we can use the same "copy each argument into the parameter region" algorithm that we use for scalar arguments. This may change when we start modeling destructors of temporaries, but for now this is the last part of <rdar://problem/12137950>. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164830 91177308-0d34-0410-b5e6-96231b3b80d8
-
Jordan Rose authored
An rvalue has no address, but calling a C++ member function requires a 'this' pointer. This commit makes the analyzer create a temporary region in which to store the struct rvalue and use as a 'this' pointer whenever a member function is called on an rvalue, which is essentially what CodeGen does. More of <rdar://problem/12137950>. The last part is tracking down the C++ FIXME in array-struct-region.cpp. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164829 91177308-0d34-0410-b5e6-96231b3b80d8
-
- Sep 05, 2012
-
-
Jordan Rose authored
Add a FIXME to the test while I track down the real problem. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163222 91177308-0d34-0410-b5e6-96231b3b80d8
-
Jordan Rose authored
The problem is that the value of 'this' in a C++ member function call should always be a region (or NULL). However, if the object is an rvalue, it has no associated region (only a conjured symbol or LazyCompoundVal). For now, we handle this in two ways: 1) Actually respect MaterializeTemporaryExpr. Before, it was relying on CXXConstructExpr to create temporary regions for all struct values. Now it just does the right thing: if the value is not in a temporary region, create one. 2) Have CallEvent recognize the case where its 'this' pointer is a non-region, and just return UnknownVal to keep from confusing clients. The long-term problem is being tracked internally in <rdar://problem/12137950>, but this makes many test cases pass. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163220 91177308-0d34-0410-b5e6-96231b3b80d8
-
Jordan Rose authored
This turned out to have many implications, but what eventually seemed to make it unworkable was the fact that we can get struct values (as LazyCompoundVals) from other places besides return-by-value function calls; that is, we weren't actually able to "treat all struct values as regions" consistently across the entire analyzer core. Hopefully we'll be able to come up with an alternate solution soon. This reverts r163066 / 02df4f0a. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163218 91177308-0d34-0410-b5e6-96231b3b80d8
-
- Sep 01, 2012
-
-
Jordan Rose authored
This allows us to correctly symbolicate the fields of structs returned by value, as well as get the proper 'this' value for when methods are called on structs returned by value. This does require a moderately ugly hack in the StoreManager: if we assign a "struct value" to a struct region, that now appears as a Loc value being bound to a region of struct type. We handle this by simply "dereferencing" the struct value region, which should create a LazyCompoundVal. This should fix recent crashes analyzing LLVM and on our internal buildbot. <rdar://problem/12137950> git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163066 91177308-0d34-0410-b5e6-96231b3b80d8
-