Zhongxing and I discussed by email.

Main changes:
- Removed SymIntConstraintVal and SymIntConstraint
- Added SymExpr as a parent class to SymbolData, SymSymExpr, SymIntExpr
- Added nonloc::SymExprVal to wrap SymExpr
- SymbolRef is now just a typedef of 'const SymbolData*'
- Bunch of minor code cleanups in how some methods were invoked (no functionality change)

This changes are part of a long-term plan to have full symbolic expression
trees. This will be useful for lazily evaluating complicated expressions.

llvm-svn: 67731

llvm-svn: 67726

Factor the member access specifier setting code into its own function. No intended functionality change.

llvm-svn: 67725

Handle parsing of templates in member declarations. Pass the AccessSpecifier all the way down to ActOnClassTemplate.

Doug, Sebastian: Plz review! :)

llvm-svn: 67723

llvm-svn: 67722

is of type void*.  I'll try to add the appropriate checking later.

llvm-svn: 67721

specializations can be treated as a template. Finally, we can parse
and process the first implementation of Fibonacci I wrote!

Note that this code does not handle all of the cases where
injected-class-names can be treated as templates. In particular,
there's an ambiguity case that we should be able to handle (but
can't), e.g.,

  template <class T> struct Base { }; 
  template <class T> struct Derived : Base<int>, Base<char> {
    typename Derived::Base b;       // error: ambiguous
    typename Derived::Base<double> d;  // OK 
  };

llvm-svn: 67720

Also, fix fallout from the change.

llvm-svn: 67717

templates, including in-class initializers. For example:

  template<typename T, T Divisor>
  class X {
  public:
    static const T value = 10 / Divisor;
  };

instantiated with, e.g.,

  X<int, 5>::value

to get the value '2'.

llvm-svn: 67715

is not in use).

llvm-svn: 67713

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

from previous block literals.

llvm-svn: 67696

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

static analysis.

llvm-svn: 67665

llvm-svn: 67664

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