appear between the return type and the selector. This is a separate code path
from regular attribute processing, as we only want to (a) accept only a specific
set of attributes in this place and (b) want to distinguish to clients the
context in which an attribute was added to an ObjCMethodDecl.

Currently, the attribute 'objc_ownership_returns' is the only attribute that
uses this new feature. Shortly I will add a warning for 'objc_ownership_returns'
to be placed at the end of a method declaration.

llvm-svn: 70504

the return type and selector. Haven't hooked this up to Sema yet.

llvm-svn: 70501

Just because a declaration has the same name as its containing class doesn't mean that it's a constructor. Fixes rdar://problem/6815988.

llvm-svn: 70436

llvm-svn: 70418

type and argument types are missing, and let return type deduction
happen before we give errors for returning from a noreturn block.
Radar 6441502

llvm-svn: 70413

llvm-svn: 70403

llvm-svn: 70389

to add 'CFMakeCollectable' semantics to a method.

llvm-svn: 70336

that if we're going to print an extension warning anyway, 
there's no point to changing behavior based on NoExtensions: it will 
only make error recovery worse.

Note that this doesn't cause any behavior change because NoExtensions 
isn't used by the current front-end.  I'm still considering what to do about
the remaining use of NoExtensions in IdentifierTable.cpp.

llvm-svn: 70273

'objc_ownership_cfrelease'. These are the 'release' equivalents of
'objc_ownership_retain' and 'objc_ownership_cfretain' respectively.

llvm-svn: 70235

as 'objc_ownership_cfretain' except that the method acts like a CFRetain instead
of a [... retain] (important in GC modes). Checker support is wired up, but
currently only for Objective-C message expressions (not function calls).

llvm-svn: 70218

llvm-svn: 70160

llvm-svn: 70155

support -pg, we never instrument :)

llvm-svn: 70061

This gets rid of a bunch of random InvalidDecl bools in sema, changing
us to use the following approach:

1. When analyzing a declspec or declarator, if an error is found, we 
   set a bit in Declarator saying that it is invalid.
2. Once the Decl is created by sema, we immediately set the isInvalid
   bit on it from what is in the declarator.  From this point on, sema
   consistently looks at and sets the bit on the decl.

This gives a very clear separation of concerns and simplifies a bunch
of code.  In addition to this, this patch makes these changes:

1. it renames DeclSpec::getInvalidType() -> isInvalidType().
2. various "merge" functions no longer return bools: they just set the
   invalid bit on the dest decl if invalid.
3. The ActOnTypedefDeclarator/ActOnFunctionDeclarator/ActOnVariableDeclarator
   methods now set invalid on the decl returned instead of returning an
   invalid bit byref.
4. In SemaType, refering to a typedef that was invalid now propagates the
   bit into the resultant type.  Stuff declared with the invalid typedef
   will now be marked invalid.
5. Various methods like CheckVariableDeclaration now return void and set the
   invalid bit on the decl they check.


There are a few minor changes to tests with this, but the only major bad
result is test/SemaCXX/constructor-recovery.cpp.  I'll take a look at this
next.

llvm-svn: 70020

users to specify that a method's argument is visibly retained (reference count
incremented).

llvm-svn: 70008

to the checker yet, but essentially it allows a user to specify that an
Objective-C method or C function increments the reference count of a passed
object.

llvm-svn: 70005

up to the checker yet, but essentially it allows a user to specify that an
Objective-C method or C function returns an owned an Objective-C object.

llvm-svn: 70001

by correctly propagating the fact that the type was invalid up to the
attributeRuns decl, then returning an ExprError when attributeRuns is
formed (like we do for normal declrefexprs).

llvm-svn: 69998

for scoping to match C99 even when in C89 mode.  This patch fixes this 
(eliminating a "redefinition of thisKey" error), and also prevents non-sensical
diagnostics in -pedantic mode like this:

t.m:7:8: warning: variable declaration in for loop is a C99-specific feature
  for (id thisKey in keys) ;
       ^

llvm-svn: 69760

llvm-svn: 69642

PR4023

llvm-svn: 69618

llvm-svn: 69542

call ActOnBlockError so that CurBlock gets popped.  This
fixes a crash on test/block-syntax-error.c when this new
assertion is enabled.

llvm-svn: 69464

llvm-svn: 69345

Fix a crash bug when comparing overload quality of conversion operators with conversion constructors.
Remove an atrocious amount of trailing whitespace in the overloaded operator mangler. Sorry, couldn't help myself.
Change the DeclType parameter of Sema::CheckReferenceInit to be passed by value instead of reference. It wasn't changed anywhere.
Let the parser handle C++'s irregular grammar around assignment-expression and conditional-expression.
And finally, the reason for all this stuff: implement C++ semantics for the conditional operator. The implementation is complete except for determining lvalueness.

llvm-svn: 69299

llvm-svn: 69245

with other diagnostic mapping.  In the new scheme, -Wfoo or -Wno-foo or 
-Werror=foo all override the -pedantic options, and __extension__ 
robustly silences all extension diagnostics in their scope.

An added bonus of this change is that MAP_DEFAULT goes away, meaning that
per-diagnostic mapping information can now be stored in 2 bits, doubling
the density of the Diagnostic::DiagMapping array.  This also 
substantially simplifies Diagnostic::getDiagnosticLevel.

OTOH, this temporarily introduces some "macro intensive" code in 
Diagnostic.cpp.  This will be addressed in a later patch.

llvm-svn: 69154

nested name specifiers.  Now we emit stuff like:

t.cpp:8:13: error: unknown type name 'X'
static foo::X  P;
       ~~~~ ^

instead of:

t.cpp:8:16: error: invalid token after top level declarator
static foo::X  P;
               ^

This is inspired by a really awful error message I got from 
g++ when I misspelt diag::kind as diag::Kind.

llvm-svn: 69086

ParseDeclarationSpecifiers into its own function, no
functionality change.

llvm-svn: 69083

int in a bitfield.  Shantonu found this in a gcc testsuite file.

llvm-svn: 69074

llvm-svn: 69055

llvm-svn: 69044

PR3972: Poor diagnostic with missing ')'

llvm-svn: 68932

llvm-svn: 68921

to isValidAfterIdentifierInDeclarator, as suggested by Sebastian.

llvm-svn: 68920

that I noticed working on other things.

Instead of emitting:

t2.cc:1:8: error: use of undeclared identifier 'g'
int x(*g);
       ^
t2.cc:1:10: error: expected ')'
int x(*g);
         ^
t2.cc:1:6: note: to match this '('
int x(*g);
     ^

We now only emit:

t2.cc:1:7: warning: type specifier missing, defaults to 'int'
int x(*g);
      ^


Note that the example in SemaCXX/nested-name-spec.cpp:f4 is still
not great, we now produce both of:

void f4(undef::C); // expected-error {{use of undeclared identifier 'undef'}} \
                      expected-error {{variable has incomplete type 'void'}}

The second diagnostic should be silenced by something getting marked invalid.
I don't plan to fix this though.

llvm-svn: 68919

this allows downstream diags to be properly silenced.

llvm-svn: 68917

struct xyz { int y; };
enum abc { ZZZ };

static xyz b;
abc c;

we used to produce:

t2.c:4:8: error: unknown type name 'xyz'
static xyz b;
       ^
t2.c:5:1: error: unknown type name 'abc'
abc c;
^

we now produce:

t2.c:4:8: error: use of tagged type 'xyz' without 'struct' tag
static xyz b;
       ^
       struct
t2.c:5:1: error: use of tagged type 'abc' without 'enum' tag
abc c;
^
enum

GCC produces the normal:
t2.c:4: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘b’
t2.c:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’

rdar://6783347

llvm-svn: 68914

which tries to do better error recovery when it is "obvious" that an
identifier is a mis-typed typename.  In this case, we try to parse
it as a typename instead of as the identifier in a declarator, which
gives us several options for better error recovery and immediately
makes diagnostics more useful.  For example, we now produce:

t.c:4:8: error: unknown type name 'foo_t'
static foo_t a = 4;
       ^

instead of:

t.c:4:14: error: invalid token after top level declarator
static foo_t a = 4;
             ^

Also, since we now parse "a" correctly, we make a decl for it,
preventing later uses of 'a' from emitting things like:

t.c:12:20: error: use of undeclared identifier 'a'
int bar() { return a + b; }
                   ^

I'd really appreciate any scrutiny possible on this, it 
is a tricky area.

llvm-svn: 68911