llvm-svn: 68091

disable this feature for now, to err on the side of rejecting instead
of sometimes crashing.  rdar://6326239

llvm-svn: 68088

within nested-name-specifiers, e.g., for the "apply" in

  typename MetaFun::template apply<T1, T2>::type

At present, we can't instantiate these nested-name-specifiers, so our
testing is sketchy.

llvm-svn: 68081

llvm-svn: 68077

Implement UCN support for C string literals (C99 6.4.3) and add some very basic tests. Chris Goller has graciously offered to write some test to help validate UCN support.

From a front-end perspective, I believe this code should work for ObjC @-strings. At the moment, I believe we need to tweak the code generation for @-strings (which doesn't appear to handle them). Will be investigating.

llvm-svn: 68076

llvm-svn: 68075

representation handles the various ways in which one can name a
template, including unqualified references ("vector"), qualified
references ("std::vector"), and dependent template names
("MetaFun::template apply").

One immediate effect of this change is that the representation of
nested-name-specifiers in type names for class template
specializations (e.g., std::vector<int>) is more accurate. Rather than
representing std::vector<int> as

  std::(vector<int>)

we represent it as

  (std::vector)<int>

which more closely follows the C++ grammar. 

Additionally, templates are no longer represented as declarations
(DeclPtrTy) in Parse-Sema interactions. Instead, I've introduced a new
OpaquePtr type (TemplateTy) that holds the representation of a
TemplateName. This will simplify the handling of dependent
template-names, once we get there.

llvm-svn: 68074

assume that @catch blocks are never executed.

llvm-svn: 68072

it.  Will discuss offline whether symbolic regions should by typed or typeless.

llvm-svn: 68070

llvm-svn: 68069

llvm-svn: 68068

llvm-svn: 68063

 - Patch by Ed Schouten!

llvm-svn: 68061

declaration. Reject it.

llvm-svn: 68058

llvm-svn: 68052

loc::SymbolVal/nonloc::SymbolVal probing.

llvm-svn: 68049

also makes this code more correct as it transparently handles SVals that wrapped
TypedViewRegions(SymbolicRegions).

llvm-svn: 68048

 - <rdar://problem/6726511> [driver] clang does not have -msoft-float
   hooked up.

llvm-svn: 68044

Patch by David Chisnall.

llvm-svn: 68043

llvm-svn: 68042

will be called for every expression in a basic block.

llvm-svn: 68041

Layer the type information with a TypedViewRegion on top of the SymbolicRegion.

llvm-svn: 68028

 - Not particularly elegant, but my hand is forced by gcc.

Also, tweak -ccc-print-bindings output.

llvm-svn: 68027

llvm-svn: 68024

 - Rip out various bits of logic from clang-cc's dependency file gen,
   force driver to provide instead.

 - -MD output now goes to proper location
<rdar://problem/6723948> clang -MD puts dep file in /tmp with wrong name

 - -M and -MM still don't work correctly.

llvm-svn: 68022

llvm-svn: 68021

we can properly claim arguments, even if they have been translated by
the tool chain.

llvm-svn: 68020

tools, and enable them.

llvm-svn: 68019

warnings.

llvm-svn: 68018

by moving the general case to the generic x86-32 target.

llvm-svn: 68015

unused, and lacking a test case).
 - ccc is now on death row, pending some more testing and bug fixes.

llvm-svn: 68012

llvm-svn: 68011

into ParseForStatement.  Merge two tests into one.

llvm-svn: 68010

into ParseSimpleDeclaration, and improve a diagnostic.

llvm-svn: 68009

(currently unused).

llvm-svn: 68003

productions (except the already broken ObjC cases like @class X,Y;) in 
the parser that can produce more than one Decl return a DeclGroup instead
of a Decl, etc.

This allows elimination of the Decl::NextDeclarator field, and exposes
various clients that should look at all decls in a group, but which were
only looking at one (such as the dumper, printer, etc).  These have been
fixed.

Still TODO:

1) there are some FIXME's in the code about potentially using
DeclGroup for better location info.
2) ParseObjCAtDirectives should return a DeclGroup due to @class etc.
3) I'm not sure what is going on with StmtIterator.cpp, or if it can
   be radically simplified now.
4) I put a truly horrible hack in ParseTemplate.cpp.

I plan to bring up #3/4 on the mailing list, but don't plan to tackle
#1/2 in the short term.

llvm-svn: 68002

llvm-svn: 68000

Reintroduce r67870 (rval ref overloading), since I can't reproduce any test failures on i386 or x86_64. If this fails for someone, please contact me.

llvm-svn: 67999

llvm-svn: 67997

simplifies some code.

llvm-svn: 67993