Also resolve a long-working FIXME in the test case I modified.

llvm-svn: 102688

on a method declaration (radar 7822196).

llvm-svn: 102383

when they are not complete (since we could not match them up to
anything) and ensuring that enum parsing can cope with dependent
elaborated-type-specifiers. Fixes PR6915 and PR6649.

llvm-svn: 102247

arguments. Rather than having the parser call ActOnParamDeclarator
(which is a bit of a hack), call a new ActOnObjCExceptionDecl
action. We'll be moving more functionality into this handler to
perform earlier checking of @catch.

llvm-svn: 102222

statements. Instead of the @try having a single @catch, where all of
the @catch's were chained (using an O(n^2) algorithm nonetheless),
@try just holds an array of its @catch blocks. The resulting AST is
slightly more compact (not important) and better represents the actual
language semantics (good).

llvm-svn: 102221

ConsumeAndStoreUntil would stop at tok::unknown when caching an inline method
definition while SkipUntil would go past it while parsing the method.

Fixes PR 6903.

llvm-svn: 102214

try to annotate as a type first to determine whether we have a
functional-style cast. Patch by Eli Friedman, fixes PR6830.

llvm-svn: 102161

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

Objective-C class message expression into a type from the parser
(which was doing so in two places) to Action::getObjCMessageKind()
which, in the case of Sema, reduces the number of name lookups we need
to perform.

llvm-svn: 102026

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

llvm-svn: 101943

llvm-svn: 101941

function declaration, since it may end up being changed (e.g.,
"extern" can become "static" if a prior declaration was static). Patch
by Enea Zaffanella and Paolo Bolzoni.

llvm-svn: 101826

intended for redeclarations, fixing those that need it. Fixes PR6831.

This uncovered an issue where the C++ type-specifier-seq parsing logic
would try to perform name lookup on an identifier after it already had
a type-specifier, which could also lead to spurious ambiguity errors
(as in PR6831, but with a different test case).

llvm-svn: 101419

in case it ends up doing something that might trigger diagnostics
(template instantiation, ambiguity reporting, access
reporting). Noticed while working on PR6831.

llvm-svn: 101412

llvm-svn: 101311

llvm-svn: 101284

super message sends in Objective-C. No actual functionality change
here, but it provides a hook so that Sema can typo-correct the
receiver in some cases.

llvm-svn: 101207

ActOnClassTemplateSpecialization and being very confused.
Fixes PR6514 (for non-templated-scope friends).

llvm-svn: 101198

PR6207.

llvm-svn: 101119

llvm-svn: 101073

rdar://7853261

llvm-svn: 101048

llvm-svn: 101026

by David Chisnall

llvm-svn: 101024

llvm-svn: 101022

This also fixes cases where super is used in a block in a
method which isn't valid.

llvm-svn: 101021

fields to two 16-bit values instead of using bitfields.

llvm-svn: 101020

type, instead of having sema do it.

llvm-svn: 101016

llvm-svn: 101006

LookupInObjCMethod.  Doing so allows all sorts of invalid code
to slip through to codegen.  This patch does not change the 
AST representation of super, though that would now be a natural
thing to do since it can only be in the receiver position and
in the base of a ObjCPropertyRefExpr.

There are still several ugly areas handling super in the parser,
but this is definitely a step in the right direction.

llvm-svn: 100959

when they're instantiated.  Merge the note into the -Wreorder warning;  it
doesn't really contribute much, and it was splitting a thought across diagnostics
anyway.  Don't crash in the parser when a constructor's initializers end in a
comma and there's no body;  the recovery here is still terrible, but anything's
better than a crash.

llvm-svn: 100922

Declarator that depends on it.  This fixes several redundant errors and bad
recoveries.

llvm-svn: 100779

methods. wip.

llvm-svn: 100734

isNotEmpty calls.

llvm-svn: 100722

definitions, e.g., after 

  -

or

  - (id)

we'll find all of the "likely" instance methods that one would want to
declare or define at this point. In the latter case, we only produce
results whose return types match "id".

llvm-svn: 100587

declared in categories.

llvm-svn: 100577

e.g., the right-hand side of binary expressions.

llvm-svn: 100526

returned by SetTypeSpecType.

llvm-svn: 100443

when parsing. Fixes radar 7822196.

llvm-svn: 100248

ares are not separated by ':' (radar 7030268).

llvm-svn: 100040