| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
This implements test/Sema/stmt_exprs.c
llvm-svn: 40465
|
|
|
|
| |
llvm-svn: 40388
|
|
|
|
| |
llvm-svn: 40381
|
|
|
|
| |
llvm-svn: 40162
|
|
|
|
|
|
| |
invalid arguments.
llvm-svn: 40161
|
|
|
|
|
|
|
| |
Since that point is now long gone, we should rename LexerToken to
Token, as it is the only kind of token we have.
llvm-svn: 40105
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 39989
|
|
|
|
|
|
| |
which makes it multithread clean.
llvm-svn: 39863
|
|
|
|
|
|
|
|
|
|
|
| |
typedef float float4 __attribute__((vector_size (16)));
void addFloat4(float4 a, float4 b) {
float4 temp;
}
make sure to add 'temp' to the stmt tree as a declstmt.
llvm-svn: 39722
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Small cleanup. No need to assign to a variable before returning.
llvm-svn: 39697
|
|
|
|
| |
llvm-svn: 39677
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 39644
|
|
|
|
|
|
|
|
|
|
| |
Submitted by:
Reviewed by:
Changed the name of DeclSpec.AddAttribute and Declarator.AddAttribute to
AddAttributes(). Also added some (much needed) comments. While documenting,
realized I could simplify & tighten up Declarator.AddAttributes...
llvm-svn: 39640
|
|
|
|
| |
llvm-svn: 39635
|
|
|
|
|
|
|
|
| |
2005-10-18-VariableSizedElementCrash.c:5:41: warning: expected ';' at end of declaration list
struct bar {foo f1; int f2:3; int f3:4} *p = (struct bar *) pi;
^
llvm-svn: 39633
|
|
|
|
|
|
|
|
|
|
|
|
| |
e.g.:
struct A {
;
int X;;
const;
};
llvm-svn: 39632
|
|
|
|
|
|
|
|
| |
Submitted by:
Reviewed by:
Add AttributeList.cpp (for "raw" attributes).
llvm-svn: 39626
|
|
|
|
|
|
|
|
|
|
|
| |
declspecs,
like: int X, Y, Z;
This is required for the code gen to get to all of the declarations in a
DeclStmt, and should simplify some other code.
llvm-svn: 39623
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Submitted by:
Reviewed by:
Fixed a bug in the parser's handling of attributes on pointer declarators.
For example, the following code was producing a syntax error...
int *__attribute(()) foo;
attrib.c:10:25: error: expected identifier or '('
int *__attribute(()) foo;
^
Changed Parser::ParseTypeQualifierListOpt to not consume the token following
an attribute declaration.
Also added LexerToken::getName() convenience method...useful when tracking
down errors like this.
llvm-svn: 39602
|
|
|
|
|
|
|
| |
after the expr along with the expr. If we don't do this, the semicolon
gets parsed as a nullstmt, which makes the generated AST very strange.
llvm-svn: 39600
|
|
|
|
|
|
|
|
|
| |
Reviewed by: Chris Lattner
- Update the parsing of references. We allow "restrict" but not "const"
or "volatile".
llvm-svn: 39567
|
|
|
|
|
|
|
|
|
|
| |
Submitted by:
Reviewed by:
After speaking with Chris, decided not to have GCC "attributes" inherit
from Decl. This will enable us to grow the attribute hierarchy over time
without effecting Decls.
llvm-svn: 39543
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Submitted by:
Reviewed by:
Implement support for GCC __attribute__.
- Implement "TODO" in Parser::ParseAttributes. Changed the return type from
void to Parser::DeclTy. Changed all call sites to accept the return value.
- Added Action::ParseAttribute and Sema::ParseAttribute to return an
appropriate AST node. Added new node AttributeDecl to Decl.h.
Still to do...hook up to the Decl...
llvm-svn: 39539
|
|
|
|
|
|
|
|
|
|
|
|
| |
Submitted by:
Reviewed by:
- ParseForStatement(): Put back a test/assignment. My removal of
ParseExprStmt() was a bit over zealous:-(thanks to Chris for pointing it out)
- Add assert to VisitDeclStmt().
- Removed an out-of-date FIXME
- Added some curlies for a couple multi-line calls to Diag().
llvm-svn: 39528
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Submitted by:
Reviewed by:
Implement some FIXME's that stand in the way of fully typechecking "for"
statements. This involved:
- Adding a DeclStmt AST node (with statement visitor). The DeclStmt
printer is preliminary.
- Added a ParseDeclStmt action, called from Parser::ParseForStatement()
and Parser::ParseStatementOrDeclaration(). DID NOT add to
Parser::ParseIdentifierStatement()...probably could have, however didn't
really understand the context of this rule (will speak with Chris).
- Removed ParseExprStmt (and it's clients)...it was vestigial.
llvm-svn: 39518
|
|
|
|
| |
llvm-svn: 39511
|
|
|
|
| |
llvm-svn: 39510
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
void foo() {
if (0) break;
abc:
def:
hij:
break;
into:
void foo() {
if ((0)')
;
abc:
def:
hij:
;
instead of dropping the if and labels (due to break not being in a loop).
llvm-svn: 39508
|
|
|
|
| |
llvm-svn: 39506
|
|
|
|
|
|
|
|
|
|
|
| |
Submitted by: Bill Wendling
Reviewed by: Chris Lattner
- Initial support for C++ references. Adding to the AST and Parser.
Skeletal support added in the semantic analysis portion. Full semantic
analysis is to be done soon.
llvm-svn: 39496
|
|
|
|
| |
llvm-svn: 39490
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
etc.
llvm-svn: 39447
|
|
|
|
|
|
| |
is enabled.
llvm-svn: 39430
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
enum {
CSSM_FALSE = 0,
CSSM_TRUE = !&CSSM_FALSE
};
t.c:4:15: error: invalid lvalue in address expression
CSSM_TRUE = !&CSSM_FALSE
^
t.c:6:2: error: expected '}'
};
^
t.c:2:6: error: to match this '{'
enum {
^
3 diagnostics generated.
We now issue:
t.c:4:15: error: invalid lvalue in address expression
CSSM_TRUE = !&CSSM_FALSE
^
1 diagnostics generated.
llvm-svn: 39420
|
|
|
|
|
|
| |
tokens is found.
llvm-svn: 39419
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Submitted by:
Reviewed by:
Misc. changes driven by getting "carbon.h" to compile...
- Added ParseCharacterConstant() hook to Action, Sema, etc.
- Added CheckAssignmentOperands() & CheckCommaOperands() to Sema.
- Added CharacterLiteral AST node.
- Fixed CallExpr instantiation - install the correct type.
- Install a bunch of temp types and annotate with FIXME's.
llvm-svn: 39416
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
IntegerConstant->StringLiteral).
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
|
|
|
|
|
|
|
| |
rename FloatingConstant->FloatingLiteral
rename StringExpr->StringLiteral
llvm-svn: 39341
|
|
|
|
| |
llvm-svn: 39338
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
actually add it into the declspec for the type being parsed. This allows us
to do correct semantic analysis on:
typedef int bar;
int foo() {
bar a;
return a;
}
This reduces # errors parsing carbon.h from 731 to 654.
llvm-svn: 39321
|
|
|
|
| |
llvm-svn: 39313
|
|
|
|
|
|
|
| |
the EnumDecl when the enum type is complete. This allows us to detect
redefinitions of enums.
llvm-svn: 39300
|