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

llvm-svn: 67663

precise than it used to be.

llvm-svn: 67662

llvm-svn: 67661

llvm-svn: 67660

failure to perform a declaration. Instead, explicitly note semantic
failures that occur during template parsing with a DeclResult. Fixes
PR3872.

llvm-svn: 67659

llvm-svn: 67658

llvm-svn: 67657

llvm-svn: 67656

autoconf directory, but these paths need to be relative to the main
source directory.

llvm-svn: 67655

llvm-svn: 67654

llvm-svn: 67653

llvm-svn: 67652

The configure line had --disable-bootstrap, but it was not
clear that this is essential.

llvm-svn: 67651

llvm-svn: 67650

llvm-svn: 67649

of "object type" rather than the C definition of "object type". The
difference is that C's "object type" excludes incomplete types such as

  struct X;

However, C's definition also makes it far too easy to use isObjectType
as a means to detect incomplete types when in fact we should use other
means (e.g., Sema::RequireCompleteType) that cope with C++ semantics,
including template instantiation.

I've already audited every use of isObjectType and isIncompleteType to
ensure that they are doing the right thing for both C and C++, so this
is patch does not change any functionality.

llvm-svn: 67648

llvm-svn: 67647

llvm-svn: 67646

 - -emit-llvm no longer changes what compilation steps are done.

 - -emit-llvm and -emit-llvm -S write output files with .o and .s
    suffixes, respectively.

 - <rdar://problem/6714125> clang-driver should support -O4 and -flto,
   like llvm-gcc

llvm-svn: 67645

types; add another use of RequireCompleteType.

llvm-svn: 67644