Treat @package the same as @public. The documentation for @package says it is analogous to private_extern for variables/functions. Fully implementing this requires some kind of linker support (so access is denied to code outside the classes executable image). I don't believe GCC fully implements this semantic. Will discuss with Fariborz offline.

llvm-svn: 67755

llvm-svn: 67754

tools with the name of the option replace, and arguments rendered
separately.

llvm-svn: 67753

llvm-svn: 67752

llvm-svn: 67748

analysis engine.

llvm-svn: 67747

llvm-svn: 67746

llvm-svn: 67741

CodeGenModule.  Once there, add a new NoCommon option to
it and implement -fno-common.

llvm-svn: 67735

llvm-svn: 67734

llvm-svn: 67733

llvm-svn: 67732

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