llvm-svn: 67710

llvm-svn: 67708

the declarations of member classes are instantiated when the owning
class template is instantiated. The definitions of such member classes
are instantiated when a complete type is required.

This change also introduces the injected-class-name into a class
template specialization.

llvm-svn: 67707

... arguments.

llvm-svn: 67706

terminated with an EOF token.  The condition it is trying to check for is
handled by this code above.

    // Empty arguments are standard in C99 and supported as an extension in
    // other modes.
    if (ArgTokens.empty() && !Features.C99)
      Diag(Tok, diag::ext_empty_fnmacro_arg);

llvm-svn: 67705

llvm-svn: 67703

llvm-svn: 67702

Also fixes SDISel so it *does not* force promote return value if the function is not marked signext / zeroext.

llvm-svn: 67701

llvm-svn: 67700

llvm-svn: 67697

from previous block literals.

llvm-svn: 67696

llvm-svn: 67695

llvm-svn: 67694

stoppoint nodes around until Legalize; doing this
imposed an ordering on a sequence of loads that
came from different lines, interfering with scheduling.

llvm-svn: 67692

llvm-svn: 67691

llvm-svn: 67689

llvm-svn: 67688

llvm-svn: 67687

llvm-svn: 67686

llvm-svn: 67685

llvm-svn: 67684

 - This is really gross, but its the easiest way to match gcc. Once we
   are confident in the driver, we can try and push these translations
   down into tools.

 - No test cases for this yet, it's hard to see the effects of these
   translations before the gcc tool argument translation is pulled
   over.

 - Interaction with "unused argument" warning hasn't been worked out
   yet.

 - <rdar://problem/6717359> [driver] implement toolchain specific
   argument translation.

"It's horrible in here."

llvm-svn: 67683

call, we should treat "i64 zext" as the start of a constant expr, but
"i64 0 zext" as an argument with an obsolete attribute on it (this form
is already tested by test/Assembler/2007-07-30-AutoUpgradeZextSext.ll).

Make the autoupgrade logic more discerning to avoid treating "i64 zext"
as an old-style attribute, causing us to reject a valid constant expr.
This fixes PR3876.

llvm-svn: 67682

llvm-svn: 67681

we aren't going to support. For example:
  clang -Xarch_i386 -S -Xarch_i386 -o -Xarch_i386 myi386asm.s ...

llvm-svn: 67680

matches the flag in Options.def).

llvm-svn: 67679

representing symbolic expressions like 'x'+3 and 'x'+'y'. The design is
subjected to change later when we fix the class hierarchy of symbolic
expressions.

llvm-svn: 67678

llvm-svn: 67677

 - Lift ArgList to a base class for InputArgList and DerivedArgList.
 
 - This is not a great decomposition, but it does embed the
   translation into the type system, and keep things efficient for
   tool chains that don't want to do any translation.

 - No intended functionality change.

Eventually I hope to get rid of tool chain specific translation and
have each tool do the right thing, but for now this is the easiest way
to match gcc precisely (which is good for testing).

llvm-svn: 67676

Do not ignore DW_TAG_class_type!

llvm-svn: 67675

llvm-svn: 67674

llvm-svn: 67673

class C {
    C() { }
    
    int a;
};

C::C() : a(10) { }

We also diagnose when initializers are used on declarations that aren't constructors:

t.cpp:1:10: error: only constructors take base initializers
void f() : a(10) { }
         ^

Doug and/or Sebastian: I'd appreciate a review, especially the nested-name-spec test results (from the looks of it we now match gcc in that test.)

llvm-svn: 67672

llvm-svn: 67671

llvm-svn: 67669

llvm-svn: 67668

llvm-svn: 67667

not going to persue this further at this time.

llvm-svn: 67666

static analysis.

llvm-svn: 67665

llvm-svn: 67664