C++ grammatical constructs that show up in top-level (namespace-level)
declarations, member declarations, template declarations, statements,
expressions, conditions, etc. For example, we now provide a pattern
for
static_cast<type>(expr)
when we can have an expression, or
using namespace identifier;
when we can have a using directive.
Also, improves the results of code completion at the beginning of a
top-level declaration. Previously, we would see value names (function
names, global variables, etc.); now we see types, namespace names,
etc., but no values.
llvm-svn: 93134
All statements that involve conditions can now hold on to a separate
condition declaration (a VarDecl), and will use a DeclRefExpr
referring to that VarDecl for the condition expression. ForStmts now
have such a VarDecl (I'd missed those in previous commits).
Also, since this change reworks the Action interface for
if/while/switch/for, use FullExprArg for the full expressions in those
expressions, to ensure that we're emitting
Note that we are (still) not generating the right cleanups for
condition variables in for statements. That will be a follow-on
commit.
llvm-svn: 89817
The following attributes are currently supported in C++0x attribute
lists (and in GNU ones as well):
- align() - semantics believed to be conformant to n3000, except for
redeclarations and what entities it may apply to
- final - semantics believed to be conformant to CWG issue 817's proposed
wording, except for redeclarations
- noreturn - semantics believed to be conformant to n3000, except for
redeclarations
- carries_dependency - currently ignored (this is an optimization hint)
llvm-svn: 89543
declarators are parsed primarily within a single function (at least for
these cases). Remove some excess diagnostics arising during parse failures.
llvm-svn: 85924
ExpectAndConsume instead of custom diag logic. This gets us an
insertion hint and positions the ; at the end of the line
instead of on the next token. Before:
t.c:5:1: error: expected ';' after return statement
}
^
after:
t.c:4:11: error: expected ';' after return statement
return 4
^
;
llvm-svn: 73315
redundant functionality. The result (ASTOwningVector) lives in
clang/Parse/Ownership.h and is used by both the parser and semantic
analysis. No intended functionality change.
llvm-svn: 72214
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
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
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
productions (except the already broken ObjC cases like @class X,Y;) in
the parser that can produce more than one Decl return a DeclGroup instead
of a Decl, etc.
This allows elimination of the Decl::NextDeclarator field, and exposes
various clients that should look at all decls in a group, but which were
only looking at one (such as the dumper, printer, etc). These have been
fixed.
Still TODO:
1) there are some FIXME's in the code about potentially using
DeclGroup for better location info.
2) ParseObjCAtDirectives should return a DeclGroup due to @class etc.
3) I'm not sure what is going on with StmtIterator.cpp, or if it can
be radically simplified now.
4) I put a truly horrible hack in ParseTemplate.cpp.
I plan to bring up #3/4 on the mailing list, but don't plan to tackle
#1/2 in the short term.
llvm-svn: 68002
pointer. Its purpose in life is to be a glorified void*, but which does not
implicitly convert to void* or other OpaquePtr's with a different UID.
Introduce Action::DeclPtrTy which is a typedef for OpaquePtr<0>. Change the
entire parser/sema interface to use DeclPtrTy instead of DeclTy*. This
makes the C++ compiler enforce that these aren't convertible to other opaque
types.
We should also convert ExprTy, StmtTy, TypeTy, AttrTy, BaseTy, etc,
but I don't plan to do that in the short term.
The one outstanding known problem with this patch is that we lose the
bitmangling optimization where ActionResult<DeclPtrTy> doesn't know how to
bitmangle the success bit into the low bit of DeclPtrTy. I will rectify
this with a subsequent patch.
llvm-svn: 67952
Introduce a new PrettyStackTraceDecl.
Use it to add the top level LLVM IR generation stuff in
Backend.cpp to stack traces. We now get crashes like:
Stack dump:
0. Program arguments: clang t.c -emit-llvm
1. <eof> parser at end of file
2. t.c:1:5: LLVM IR generation of declaration 'a'
Abort
for IR generation crashes.
llvm-svn: 66153
parser. For example, we now print out:
0. t.c:5:10: in compound statement {}
1. t.c:3:12: in compound statement {}
2. clang t.c -fsyntax-only
llvm-svn: 66108
multiple sequential case statements instead of doing it with recursion. This
fixes a problem where we run out of stack space parsing 100K directly nested
cases.
There are a couple other problems that prevent this from being useful in
practice (right now the example only parses correctly with -disable-free and
doesn't work with -emit-llvm), but this is a start.
I'm not including a testcase because it is large and uninteresting for
regtesting.
Sebastian, I would appreciate it if you could scrutinize the smart pointer
gymnastics I do.
llvm-svn: 66011
This shrinks OwningResult by one pointer. Since it is no longer larger than OwningPtr, merge the two.
This leads to simpler client code and speeds up my benchmark by 2.7%.
For some reason, this exposes a previously hidden bug, causing a regression in SemaCXX/condition.cpp.
llvm-svn: 63867
Substantially improve error recovery after broken if conditions by
parsing the full if when we have a semantic error instead of using
parser recovery techniques to recover from a semantic error.
This fixes rdar://6094870 - spurious error after invalid 'if' condition
llvm-svn: 60929
"else" clause, e.g.,
if (int X = foo()) {
} else {
if (X) { // warning: X is always zero in this context
}
}
Fixes rdar://6425550 and lets me think about something other than
DeclContext.
llvm-svn: 60858
post-decrement, including support for generating all of the built-in
operator candidates for these operators.
C++ and C have different rules for the arguments to the builtin unary
'+' and '-'. Implemented both variants in Sema::ActOnUnaryOp.
In C++, pre-increment and pre-decrement return lvalues. Update
Expr::isLvalue accordingly.
llvm-svn: 59638
and let the clients push whatever they want into the DiagnosticInfo
instead of hard coding a few forms. Also switch various clients to
use Diag(Tok, ...) instead of Diag(Tok.getLocation(), ...) as the
canonical form to simplify the code a bit.
llvm-svn: 59509
1. In the top level of ParseStatementOrDeclaration, don't eat a } if we
just parsed a statement if it list there. Also, don't even bother
emitting an error about a missing semicolon if the statement had a
bug (an rbrace is fine).
2. In do/while parsing, don't require a 'while' to be present if the do
body didn't parse.
This allows us to generate a clean diagnostic for this code:
t.c:1:22: error: expected expression
void foo (void) { do . while (0); }
^
Thanks to Neil for pointing this out.
llvm-svn: 59256
'ParseTentative.cpp' implements the functionality needed to resolve ambiguous C++ statements, to either a declaration or an expression, by "tentatively parsing" them.
llvm-svn: 57084
-Scoping in C99 works good for C++ too, remove the C++-specific comments.
If someone thinks that the C++-specific comments are necessary for clarification, let me know and I'll put them back on.
llvm-svn: 56078
-Remove ParseExpressionWithLeadingIdentifier and ParseAssignmentExprWithLeadingIdentifier.
-Separate ParseLabeledStatement from ParseIdentifierStatement.
llvm-svn: 53376
lib dir and move all the libraries into it. This follows the main
llvm tree, and allows the libraries to be built in parallel. The
top level now enforces that all the libs are built before Driver,
but we don't care what order the libs are built in. This speeds
up parallel builds, particularly incremental ones.
llvm-svn: 48402
