...and hopefully unbreak buildbots. My apologies!

llvm-svn: 163267

These types are defined differently on 32-bit and 64-bit platforms, and
trying to offer a fixit for one platform would only mess up the format
string for the other. The Apple-recommended solution is to cast to a type
that is known to be large enough and always use that to print the value.

This should only have an impact on compile time if the format string is
incorrect; in cases where the format string matches the definition on the
current platform, no warning will be emitted.

<rdar://problem/9135072&12164284>

llvm-svn: 163266

No functionality change.

llvm-svn: 163265

While destructors will continue to not be inlined (unless the analyzer
config option 'c++-inlining' is set to 'destructors'), leaving them out
of the CFG is an incomplete model of the behavior of an object, and
can cause false positive warnings (like PR13751, now working).

Destructors for temporaries are still not on by default, since
(a) we haven't actually checked this code to be sure it's fully correct
    (in particular, we probably need to be very careful with regard to
    lifetime-extension when a temporary is bound to a reference,
    C++11 [class.temporary]p5), and
(b) ExprEngine doesn't actually do anything when it sees a temporary
    destructor in the CFG -- not even invalidate the object region.

To enable temporary destructors, set the 'cfg-temporary-dtors' analyzer
config option to '1'. The old -cfg-add-implicit-dtors cc1 option, which
controlled all implicit destructors, has been removed.

llvm-svn: 163264

llvm-svn: 163262

If a region is binded to a symbolic value, we should track the symbol.

(The code I changed was not previously exercised by the regression
tests.)

llvm-svn: 163261

This region is set as interesting as part of trackNullOrUndefValue call,
no need to mark it as interesting twice.

llvm-svn: 163260

llvm-svn: 163253

llvm-svn: 163252

Patch by Brooks Davis.

llvm-svn: 163249

At the moment, we implictly check compatibility between the python
bindings and libclang, as the python bindings will fail to load in
case a method we use in libclang is not available.

This patch makes the use of this compatibility check explicit and introduces a
flag to optionally disable the check. This will allow us to further harden the
compatibility check, but it also gives the user the possibility to disable the
compatibility check to evaluate compatibility with older libclang versions.

I added documentation that makes clear the python bindings are only tested
with the libclang version they have been shipped with.

llvm-svn: 163238

expression involving temporaries.

llvm-svn: 163237

type is an unqualified objc pointer in arc. Treat it just
as being treated in c++98. This fixes a bogus vararg warning
with -std=c++11. //rdar://12229679

llvm-svn: 163236

llvm-svn: 163232

llvm-svn: 163226

of a c-function for what it is. Otherwise, this func
is treated as an overloadable c-function resulting in
a crash much later. // rdar://11743706

llvm-svn: 163224

Add a FIXME to the test while I track down the real problem.

llvm-svn: 163222

llvm-svn: 163221

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.

llvm-svn: 163220

No intended functionality change.

llvm-svn: 163219

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 / 02df4f0aef142f00d4637cd851e54da2a123ca8e.

llvm-svn: 163218

Due to DynTypedNode the basic dynamically typed matcher interface can now be simplified.

Also switches the traversal interfaces to use DynTypedNode;
this is in preperation for the hasAncestor implementation, and
also allows us to need fewer changes when we want to add new
nodes to traverse, thus making the code a little more decoupled.

Main design concerns: I went back towards the original design
of getNodeAs to return a pointer, and switched DynTypedNode::get
to always return a pointer (in case of value types like QualType
the pointer points into the storage of DynTypedNode, thus allowing
us to treat all the nodes the same from the point of view of a
user of the DynTypedNodes.

Adding the QualType implementation for DynTypedNode was needed
for the recursive traversal interface changes.

llvm-svn: 163212

Summary: New clang-check vim integration with the 're-run the last invocation when executed from .h file' feature.

Reviewers: klimek

Reviewed By: klimek

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D35

llvm-svn: 163211

llvm-svn: 163208

llvm-svn: 163206

- UnionType is checked eariler than RecordType.

llvm-svn: 163202

llvm-svn: 163188

llvm-svn: 163182

llvm-svn: 163178

llvm-svn: 163176

implementation does not co-exist well with how the sideeffect and alignstack
attributes are handled.

llvm-svn: 163173

llvm-svn: 163161

SimpleSValBuilder processes a couple trivial identities, including 'x - x'
and 'x ^ x' (both 0). However, the former could appear with arguments of
floating-point type, and we weren't checking for that. This started
triggering an assert with r163069, which checks that a constant value is
actually going to be used as an integer or pointer.

llvm-svn: 163159

llvm-svn: 163149

llvm-svn: 163147

llvm-svn: 163146

llvm-svn: 163145

assume that if the 1st operands is an expression and the instruction mayStore,
then it is a memory definition.

llvm-svn: 163144

llvm-svn: 163143

llvm-svn: 163142