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
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
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
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
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
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
Implement the rvalue reference overload dance for returning local objects. Returning a local object first tries to find a move constructor now.
The error message when no move constructor is defined (or is not applicable) and the copy constructor is deleted is quite ugly, though.
llvm-svn: 68902
down to the ActionBase class. This eliminates dependencies of (e.g.)
DeclSpec.h on Action.h, meaning that action.h can now include these
headers and use their types directly in the actions interfaces.
This is a refactoring to support a future change, no functionality
change.
llvm-svn: 68869
clients of the analyzer to designate custom assertion routines as "noreturn"
functions from the analyzer's perspective but not the compiler's.
llvm-svn: 68746
of the range is now the ';' location. For something like this:
$ cat t2.c
#define bool int
void f(int x, int y) {
bool b = !x && y;
}
We used to produce:
$ clang-cc t2.c -ast-dump
typedef char *__builtin_va_list;
void f(int x, int y)
(CompoundStmt 0x2201f10 <t2.c:3:22, line:5:1>
(DeclStmt 0x2201ef0 <line:2:14> <----
0x2201a20 "int b =
(BinaryOperator 0x2201ed0 <line:4:10, col:16> 'int' '&&'
(UnaryOperator 0x2201e90 <col:10, col:11> 'int' prefix '!'
(DeclRefExpr 0x2201c90 <col:11> 'int' ParmVar='x' 0x2201a50))
(DeclRefExpr 0x2201eb0 <col:16> 'int' ParmVar='y' 0x2201e10))")
Now we produce:
$ clang-cc t2.c -ast-dump
typedef char *__builtin_va_list;
void f(int x, int y)
(CompoundStmt 0x2201f10 <t2.c:3:22, line:5:1>
(DeclStmt 0x2201ef0 <line:2:14, line:4:17> <------
0x2201a20 "int b =
(BinaryOperator 0x2201ed0 <col:10, col:16> 'int' '&&'
(UnaryOperator 0x2201e90 <col:10, col:11> 'int' prefix '!'
(DeclRefExpr 0x2201c90 <col:11> 'int' ParmVar='x' 0x2201a50))
(DeclRefExpr 0x2201eb0 <col:16> 'int' ParmVar='y' 0x2201e10))")
llvm-svn: 68288
failures that involve malformed types, e.g., "typename X::foo" where
"foo" isn't a type, or "std::vector<void>" that doens't instantiate
properly.
Similarly, be a bit smarter in our handling of ambiguities that occur
in Sema::getTypeName, to eliminate duplicate error messages about
ambiguous name lookup.
This eliminates two XFAILs in test/SemaCXX, one of which was crying
out to us, trying to tell us that we were producing repeated error
messages.
llvm-svn: 68251
within nested-name-specifiers, e.g., for the "apply" in
typename MetaFun::template apply<T1, T2>::type
At present, we can't instantiate these nested-name-specifiers, so our
testing is sketchy.
llvm-svn: 68081
representation handles the various ways in which one can name a
template, including unqualified references ("vector"), qualified
references ("std::vector"), and dependent template names
("MetaFun::template apply").
One immediate effect of this change is that the representation of
nested-name-specifiers in type names for class template
specializations (e.g., std::vector<int>) is more accurate. Rather than
representing std::vector<int> as
std::(vector<int>)
we represent it as
(std::vector)<int>
which more closely follows the C++ grammar.
Additionally, templates are no longer represented as declarations
(DeclPtrTy) in Parse-Sema interactions. Instead, I've introduced a new
OpaquePtr type (TemplateTy) that holds the representation of a
TemplateName. This will simplify the handling of dependent
template-names, once we get there.
llvm-svn: 68074
Sebastian Redl