llvm-svn: 102033

Objective-C++ have a more complex grammar than in Objective-C
(surprise!), because

  (1) The receiver of an instance message can be a qualified name such
  as ::I or identity<I>::type.
  (2) Expressions in C++ can start with a type.

The receiver grammar isn't actually ambiguous; it just takes a bit of
work to parse past the type before deciding whether we have a type or
expression. We do this in two places within the grammar: once for
message sends and once when we're determining whether a []'d clause in
an initializer list is a message send or a C99 designated initializer.

This implementation of Objective-C++ message sends contains one known
extension beyond GCC's implementation, which is to permit a
typename-specifier as the receiver type for a class message, e.g.,

  [typename compute_receiver_type<T>::type method];

Note that the same effect can be achieved in GCC by way of a typedef,
e.g.,

  typedef typename computed_receiver_type<T>::type Computed;
  [Computed method];

so this is merely a convenience.

Note also that message sends still cannot involve dependent types or
values.

llvm-svn: 102031

sends. Major changes include:

  - Expanded the interface from two actions (ActOnInstanceMessage,
    ActOnClassMessage), where ActOnClassMessage also handled sends to
    "super" by checking whether the identifier was "super", to three
    actions (ActOnInstanceMessage, ActOnClassMessage,
    ActOnSuperMessage). Code completion has the same changes.
  - The parser now resolves the type to which we are sending a class
    message, so ActOnClassMessage now accepts a TypeTy* (rather than
    an IdentifierInfo *). This opens the door to more interesting
    types (for Objective-C++ support).
  - Split ActOnInstanceMessage and ActOnClassMessage into parser
    action functions (with their original names) and semantic
    functions (BuildInstanceMessage and BuildClassMessage,
    respectively). At present, this split is onyl used by
    ActOnSuperMessage, which decides which kind of super message it
    has and forwards to the appropriate Build*Message. In the future,
    Build*Message will be used by template instantiation.
  - Use getObjCMessageKind() within the disambiguation of Objective-C
    message sends vs. array designators.

Two notes about substandard bits in this patch:
  - There is some redundancy in the code in ParseObjCMessageExpr and
  ParseInitializerWithPotentialDesignator; this will be addressed
  shortly by centralizing the mapping from identifiers to type names
  for the message receiver.
  - There is some #if 0'd code that won't likely ever be used---it
  handles the use of 'super' in methods whose class does not have a
  superclass---but could be used to model GCC's behavior more
  closely. This code will die in my next check-in, but I want it in
  Subversion.

llvm-svn: 102021

Keep tack of whether a base in an InitializedEntity is an inherited virtual base or not. Use this in CheckConstructorAccess.

llvm-svn: 102020

exceeds the minimum ABI alignment.

llvm-svn: 102019

llvm-svn: 102018

llvm-svn: 102016

property synthesis is using a super class ivar.

llvm-svn: 102011

Pass the InitializedEntity to Sema::CheckConstructorAccess and use it to report different diagnostics depending on which entity is being initialized.

llvm-svn: 102010

llvm-svn: 101988

llvm-svn: 101983

Fix USRs for @synthesize.
Add more USR tests.

llvm-svn: 101954

It is ok to have c++-ness inside extern "C" 
block. Fixes pr6644.

llvm-svn: 101948

llvm-svn: 101943

llvm-svn: 101941

into ContentCache::getBuffer.  This allows it to produce 
diagnostics on the broken #include line instead of without a 
location.

llvm-svn: 101939

objective-c methods. Fixes radar 7875968.

llvm-svn: 101935

about it instead of producing tons of garbage from the lexer.

It would be even better for sourcemgr to dynamically transcode (e.g.
from UTF16 -> UTF8).

llvm-svn: 101924

llvm-svn: 101921

matches how we currently handle structs, and this correctly handles
-fno-bitfield-type-align.

llvm-svn: 101918

Fix a bug which triggered the assertion I added yesterday. Basically, when we initialize the vtable pointer for a virtual base, and there was another path from the most derived class to another base with the same class type, we would use the wrong base.

llvm-svn: 101911

@encode expression. 

llvm-svn: 101907

we will print with each error that occurs during template
instantiation. When the backtrace is longer than that, we will print
N/2 of the innermost backtrace entries and N/2 of the outermost
backtrace entries, then skip the middle entries with a note such as:

  note: suppressed 2 template instantiation contexts; use
  -ftemplate-backtrace-limit=N to change the number of template
  instantiation entries shown

This should eliminate some excessively long backtraces that aren't
providing any value.

llvm-svn: 101882

llvm-svn: 101878

This mirror's Dan's patch for llvm-gcc in r97989, and
fixes the miscompilation in PR6525.  There is some contention
over whether this is the right thing to do, but it is the
conservative answer and demonstrably fixes a miscompilation.

llvm-svn: 101877

llvm-svn: 101871

llvm-svn: 101868

llvm-svn: 101865

of buildbots with:

error: 'error' diagnostics expected but not seen: 
  Line 9: too few elements in vector initialization (expected 8 elements, have 2)
1 warning and 1 error generated.

llvm-svn: 101864

llvm-svn: 101863

actual delete expressions, not just new expressions.

llvm-svn: 101861

llvm-svn: 101859

llvm-svn: 101857

associated with a new expression if -fno-exceptions is set.

llvm-svn: 101841

will already have done so when the template is declared.

llvm-svn: 101838

Only suppress the "extern variable has an initializer" warning when the extern entity being initialized is const.

llvm-svn: 101821

since it makes sense there to have const extern variables. Fixes
PR6495.

llvm-svn: 101818

weird; yes, it's what GCC does. Almost.

llvm-svn: 101803

llvm-svn: 101800

llvm-svn: 101797