We no longer associate the correct HTML file with plist diagnostic.
Fall out from r162028.

llvm-svn: 162071

diagnostic before we have a source manager.

llvm-svn: 162070

llvm-svn: 162069

elaborated type specifier in template instantiation: such a specifier is always
valid because it must be specified within the definition of the type.

llvm-svn: 162068

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

rdar://12117935

llvm-svn: 162066

current available documentation.

llvm-svn: 162065

constraints we don't recognize.

llvm-svn: 162064

llvm-svn: 162063

Noticed on inspection.

llvm-svn: 162062

It is not my plan to duplicate the entire ARM instruction set with
predicated versions. We need a way of representing predicated
instructions in SSA form without requiring a separate opcode.

Then the pseudo-instructions can go away.

llvm-svn: 162061

Use the target independent select analysis hooks.

llvm-svn: 162060

Select instructions pick one of two virtual registers based on a
condition, like x86 cmov. On targets like ARM that support predication,
selects can sometimes be eliminated by predicating the instruction
defining one of the operands.

Teach PeepholeOptimizer to recognize select instructions, and ask the
target to optimize them.

llvm-svn: 162059

llvm-svn: 162056

llvm-svn: 162055

tokens we don't know how to handle; this should aid when debugging.

llvm-svn: 162053

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

llvm-svn: 162052

simple asm.

llvm-svn: 162051

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

llvm-svn: 162048

"command regex."  It's now more readable and
grammatically correct.

<rdar://problem/12115962>

llvm-svn: 162047

are materialized.

<rdar://problem/12105013>

llvm-svn: 162046

// rdar://12107381

llvm-svn: 162045

llvm-svn: 162044

this information to determine valid MC operands.  This will also be used for
semantic analysis.

llvm-svn: 162043

llvm-svn: 162042

llvm-svn: 162040

llvm-svn: 162039

llvm-svn: 162038

llvm-svn: 162037

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

llvm-svn: 162036

llvm-svn: 162035

llvm-svn: 162034

declaration it was attached to.

llvm-svn: 162033

llvm-svn: 162032

Fixed some renaming detritus in the comments, and an unused variable warning. Thanks to David Blaikie and Manuel Klimek for the comments

llvm-svn: 162031

llvm-svn: 162030

Remove "range_iterator" from PathDiagnosticPiece and just use ArrayRef<SourceRange> for ranges.  This 
removes conceptual clutter, and can allow us to easy migrate to C++11 style for-range loops if we
ever move to using C++11 in Clang.

llvm-svn: 162029

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

Matchers related to DeclStmt for matching the count of declarations, a particular declaration within the statement, and single-Decl DeclStmts.

llvm-svn: 162027