The idea is to eventually place all analyzer options under
"analyzer-config". In addition, this lays the ground for introduction of
a high-level analyzer mode option, which will influence the
default setting for IPAMode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173385 91177308-0d34-0410-b5e6-96231b3b80d8
More generally, this adds a new configuration option 'c++-inlining', which
controls which C++ member functions can be considered for inlining. This
uses the new -analyzer-config table, so the cc1 arguments will look like this:
... -analyzer-config c++-inlining=[none|methods|constructors|destructors]
Note that each mode implies that all the previous member function kinds
will be inlined as well; it doesn't make sense to inline destructors
without inlining constructors, for example.
The default mode is 'methods'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163004 91177308-0d34-0410-b5e6-96231b3b80d8
This allows us to better reason about status objects, like Clang's own
llvm::Optional (when its contents are trivially destructible), which are
often intended to be passed around by value.
We still don't inline constructors for temporaries in the general case.
<rdar://problem/11986434>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162681 91177308-0d34-0410-b5e6-96231b3b80d8
This is analogous to our handling of pointer dereferences: if we
dereference a pointer that may or may not be null, we assume it's non-null
from then on.
While some implementations of C++ (including ours) allow you to call a
non-virtual method through a null pointer of object type, it is technically
disallowed by the C++ standard, and should not prune out any real paths in
practice.
[class.mfct.non-static]p1: A non-static member function may be called
for an object of its class type, or for an object of a class derived
from its class type...
(a null pointer value does not refer to an object)
We can also make the same assumption about function pointers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161992 91177308-0d34-0410-b5e6-96231b3b80d8
This change is necessary when the variable is a const reference and we need
the l-value of the construct expr. After that, when binding the variable,
recover the lazy compound value when the variable is not a reference.
In Environment, use the value of a no-op cast expression when it has one.
Otherwise, blast-through it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122388 91177308-0d34-0410-b5e6-96231b3b80d8
implicit lvalue-to-rvalue casts that John McCall
recently introduced. This causes a whole bunch
of logic in the analyzer for handling lvalues
to vanish. It does, however, raise a few issues
in the analyzer w.r.t to modeling various constructs
(e.g., field accesses to compound literals).
The .c/.m analysis test cases that fail are
due to a missing lvalue-to-rvalue cast that
will get introduced into the AST. The .cpp
failures were more than I could investigate in
one go, and the patch was already getting huge.
I have XFAILED some of these tests, and they
should obviously be further investigated.
Some highlights of this patch include:
- CFG no longer requires an lvalue bit for
CFGElements
- StackFrameContext doesn't need an 'asLValue'
flag
- The "VisitLValue" path from GRExprEngine has
been eliminated.
Besides the test case failures (XFAILed), there
are surely other bugs that are fallout from
this change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@121960 91177308-0d34-0410-b5e6-96231b3b80d8
to be consistent with the type of 'this' expr in the method.
此行及以下内容将会被忽略--
M test/Analysis/method-call.cpp
M include/clang/Checker/PathSensitive/GRExprEngine.h
M lib/Checker/GRCXXExprEngine.cpp
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@120094 91177308-0d34-0410-b5e6-96231b3b80d8
Dominic Chen