The previous naming scheme was confusing, since it resulted in both the Parser and Action modules having methods with the same name. In addition, the Action module never does any parsing...
llvm-svn: 41986
2. Fixes all allowable key-words used as selectors.
3. Template to do the messaging parse.
4. A test case for all allowable selector names.
llvm-svn: 41723
warn about the last stmt in a stmtexpr, f.e. there should be no warning for:
int maxval_stmt_expr(int x, int y) {
return ({int _a = x, _b = y; _a > _b ? _a : _b; });
}
llvm-svn: 41655
Before this commit, we crashed in ParseBinOp...
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang -parse-ast-check compound_literal.c
SemaExpr.cpp:1298: failed assertion `(rhs != 0) && "ParseBinOp(): missing right expression"'
With this commit, we still crash in the newly added action ParseCompoundLiteral (which is progress:-)
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang -parse-ast-check compound_literal.c
SemaExpr.cpp:478: failed assertion `(Op != 0) && "ParseCompoundLiteral(): missing expression"'
The crash go away once the actions return AST nodes. I will do this in a separate commit.
llvm-svn: 40032
Reviewed by: Chris Lattner
- Fix for C++ casting operators failing during parsing. Deriving the C++ cast
expressions from CastExpr was the wrong way to go. Its constructor creates
null QualTypes in one of its constructors. This doesn't work well with how
the C++ casting expression class wanted to do things. Derive just from Expr
instead.
llvm-svn: 39714
out of the llvm namespace. This makes the clang namespace be a sibling of
llvm instead of being a child.
The good thing about this is that it makes many things unambiguous. The
bad things is that many things in the llvm namespace (notably data structures
like smallvector) now require an llvm:: qualifier. IMO, libsystem and libsupport
should be split out of llvm into their own namespace in the future, which will fix
this issue.
llvm-svn: 39659
where the parser emitted bogus diagnostics. Before, when compiling:
struct A { int X; } someA;
int func(int, struct A);
int test1(void *P, int C) {
return func(((C*40) + *P) / 42+P, someA);
}
we emitted:
bug3.c:7:25: error: invalid operands to binary expression ('int' and 'void')
return func(((C*40) + *P) / 42+P, someA);
~~~~~~ ^ ~~
bug3.c:7:31: error: expected ')'
return func(((C*40) + *P) / 42+P, someA);
^
bug3.c:7:16: error: to match this '('
return func(((C*40) + *P) / 42+P, someA);
^
now we only emit the first.
llvm-svn: 39474
Submitted by:
Reviewed by:
Type Checking...round 2. This checkin "breaks" parsing carbon.h. I imagine
that this will be true for the next week or so. Nevertheless, this round of
changes includes the following:
- Hacked various Expr classes to pass the appropriate TypeRef. Still have
a few more classes to touch.
- Implement type checking for ParseArraySubscriptExpr and ParseMemberReferenceExpr.
- Added a debug hook to derive the class name for Stmt/Expr nodes. Currently a
linear search...could easily optimize if important.
- Changed the name of TaggedType->TagType. Now we have TagType and TagDecl (which
are easier to remember).
- Fixed a bug in StringLiteral conversion I did a couple weeks ago. hadError was
not initialized (oops).
- changed Sema::Diag to return true. This streamlines the type checking code
considerably.
- Added many diagnositics.
This should be it!
llvm-svn: 39361
Submitted by:
Reviewed by:
Added size expression to ArrayType. This was needed to implement
Type::isIncompleteType(). At the moment, there is no support for
determining if we have a constant expression (which won't be too
difficult now that we have support for literal parsing/ast's).
Nevertheless, the parser will allow "struct foo { int a[b]; }"
(which is illegal). There is still significant work to fully analyze
array types. The good news is "carbon.h" goes from 288 bogus errors
down to 26!
llvm-svn: 39355
Submitted by:
Reviewed by:
More code to parse numeric constants. This checkin includes:
- Feedback from Chris.
- Support for parsing floating point constants.
- Moved the code to "Sema". Changed API in Action.
- More/better error diagnostics.
At this point, the parsing support should be largely complete. Next step
is to work on filling in sensible values (in IntegerLiteral/FloatLiteral).
llvm-svn: 39349
Submitted by:
Reviewed by:
First phase of parsing IntegerConstants. At the moment, all processing
is done in the Parser, not Sema. If necessary, this is easy to move.
Next steps:
- Convert well for strings to actual values (need to look @ APInt.h)
- Design the API between the Parser and Sema. Sema shouldn't have to be
concerned with any parsing issues...
llvm-svn: 39348
clang still compiled/linked/ran properly...simply a confusing name regression.
From now on I'll make sure I run "cvs diff" before committing any changes!
llvm-svn: 39342
typedef int X;
int A() {
return X;
}
int B() {
return Y;
}
as:
/Users/sabre/test.c:5:10: error: unexpected type name 'X': expected expression
return X;
^
/Users/sabre/test.c:9:10: error: use of undeclared 'Y' value
return Y;
^
llvm-svn: 39192
fundamentally requires having an AST around, so move all sema to the
AST library. This is the first step, later steps will be needed to
clean up libast.
llvm-svn: 39150
Steve Naroff