'int' vs. 'long' issue with i386.

llvm-svn: 162125

Fixes <rdar://problem/12119814>

llvm-svn: 162123

 - The SDKROOT environment variable is the de facto way to set the default SDK
   for a number of tools, join forces with them.

llvm-svn: 162116

llvm-svn: 162110

on unsafe cast of a c-function call. This is
a C-only option.

llvm-svn: 162109

GCC documents these as unsigned, but defines them as signed.

llvm-svn: 162106

llvm-svn: 162096

Initializing a reference with itself, e.g. "int &a = a;" seems like a
very bad idea.

llvm-svn: 162093

literals match the spacing introduced by the ObjC modernizer. Fixes
the rest of <rdar://problem/11889572>.

llvm-svn: 162084

declaration context, check whether the primary context---not the
current context---has any external visible declarations. Fixes
PR13616.

llvm-svn: 162083

both a waste of time, and prone to crash due to the use of the
error-recovery path in parser. Fixes <rdar://problem/12103608>, which
has been driving me nuts.

llvm-svn: 162081

llvm-svn: 162077

of silently dropping it on the floor.

llvm-svn: 162075

class templates. This fixes misalignment issues in llvm/Support/Endian.h when
built by Clang.

llvm-svn: 162074

function arguments and arguments for variadic functions are of a particular
type which is determined by some other argument to the same function call.

Usecases include:
* MPI library implementations, where these attributes enable checking that
  buffer type matches the passed MPI_Datatype;
* for HDF5 library there is a similar usecase as MPI;
* checking types of variadic functions' arguments for functions like
  fcntl() and ioctl().

llvm-svn: 162067

constraints we don't recognize.

llvm-svn: 162064

an abstract c++ class. // rdar://12095239

llvm-svn: 162052

These require special handling, which we don't currently handle.  This is being
put in place to ensure we don't do invalid symbol table lookups or try to parse
invalid assembly.  The test cases just makes sure the latter isn't happening.

llvm-svn: 162050

// rdar://12107381

llvm-svn: 162045

llvm-svn: 162038

expressions except to void, void * and their
qualified versions. // rdar://12107381

llvm-svn: 162036

declaration it was attached to.

llvm-svn: 162033

This fixes several issues:

- removes egregious hack where PlistDiagnosticConsumer would forward to HTMLDiagnosticConsumer,
but diagnostics wouldn't be generated consistently in the same way if PlistDiagnosticConsumer
was used by itself.

- emitting diagnostics to the terminal (using clang's diagnostic machinery) is no longer a special
case, just another PathDiagnosticConsumer.  This also magically resolved some duplicate warnings,
as we now use PathDiagnosticConsumer's diagnostic pruning, which has scope for the entire translation
unit, not just the scope of a BugReporter (which is limited to a particular ExprEngine).

As an interesting side-effect, diagnostics emitted to the terminal also have their trailing "." stripped,
just like with diagnostics emitted to plists and HTML.  This required some tests to be updated, but now
the tests have higher fidelity with what users will see.

There are some inefficiencies in this patch.  We currently generate the report graph (from the ExplodedGraph)
once per PathDiagnosticConsumer, which is a bit wasteful, but that could be pulled up higher in the
logic stack.  There is some intended duplication, however, as we now generate different PathDiagnostics (for the same issue)
for different PathDiagnosticConsumers.  This is necessary to produce the diagnostics that a particular
consumer expects.

llvm-svn: 162028

variables, function or label references.  The former is a potential clobber.
The latter is either an input or an output.  Unfortunately, it's difficult to
test this patch at the moment, but the added test case will eventually do so.

llvm-svn: 162026

and remove ASTContext reference (which was frequently bound to a dereferenced
null pointer) from the recursive lump of printPretty functions. In so doing,
fix (at least) one case where we intended to use the 'dump' mode, but that
failed because a null ASTContext reference had been passed in.

llvm-svn: 162011

potential crasher -- Context is sometimes a null reference (!!) here.

llvm-svn: 162007

llvm-svn: 162003

llvm-svn: 162002

Previously, we were losing path notes (in both text and plist form)
because the interesting DeclRefExpr was buried in a cast.

llvm-svn: 161999

Based on a patch by Yin Ma!

llvm-svn: 161998

late-parsed attribute is attached to an invalid declaration.

llvm-svn: 161997

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.

llvm-svn: 161992

llvm-svn: 161991

Fixes a mistake introduced in r161916.

llvm-svn: 161987

statement.  For example,

  if (x)
    __asm out dx, ax  __asm out dx, ax

results in a single inline asm statement (i.e., both "out dx, ax" statements are
predicated on if(x)).

llvm-svn: 161986

This is the other half of C++11 [class.cdtor]p4 (the destructor side
was added in r161915). This also fixes an issue with post-call checks
where the 'this' value was already being cleaned out of the state, thus
being omitted from a reconstructed CXXConstructorCall.

llvm-svn: 161981

llvm-svn: 161980

as it does something unexpected (but gcc compatible).
Suggest use of __attribute__((visibility("hidden")))
on declaration instead. // rdar://7703982

llvm-svn: 161972

Changed the alignment of an LValue to be 64 bits so that we can handle
alignment values up to half of a 64-bit address space.

llvm-svn: 161971

This is a reapplication of r161914 now that the scoping issue has been resolved
in r161966.

llvm-svn: 161967