llvm-svn: 67703

llvm-svn: 67700

llvm-svn: 67697

from previous block literals.

llvm-svn: 67696

llvm-svn: 67695

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

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

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

static analysis.

llvm-svn: 67665

llvm-svn: 67664

llvm-svn: 67663

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: 67653

llvm-svn: 67650

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

 - -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

incomplete types. RequireCompleteType is needed when the type may be
completed by instantiating a template.

llvm-svn: 67643

conceivably handle, but are defaulting to not using clang for.

llvm-svn: 67641

 - Don't default to using clang for C++ (use -ccc-clang-cxx to
   override).

 - Default to only using clang on i386 and x86_64 (use
   -ccc-clang-archs "" to override).

 - <rdar://problem/6712350> [driver] clang should not be used on
   powerpc by default
 - <rdar://problem/6705767> driver should default to -ccc-no-clang-cxx

I plan to add a warning that we are not using the clang compiler for
the given compilation so that users do not think clang is being used
in situations it isn't.

This change is motivated by the desire to be able to drop clang into a
build and have things "just work", even if it happens to get used to
compile C++ code or code for an architecture we don't support yet.

llvm-svn: 67640

Driver::ShouldUseClangCompiler.
 - No functionality change.

llvm-svn: 67639

 - <rdar://problem/6715707> driver should translate -fverbose-asm into
   -asm-verbose

llvm-svn: 67634

llvm-svn: 67633

is specified.
 - No easy way to make a safe test case for this (given where the
   driver is supposed to put temp files).

llvm-svn: 67632

 - <rdar://problem/6715818> clang doesn't honor gcc semantic that last
    -O optimization option wins.

llvm-svn: 67628

Fix the bug that Eli noticed where we wouldn't look at function decls outside the class declaration.

llvm-svn: 67627

llvm-svn: 67626

llvm-svn: 67625