| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
- Cache the "id" type in Sema...initialize ObjcIdType and TUScope (oops).
- Fix ActOnInstanceMessage to allow for "id" type receivers...still work to do (next).
llvm-svn: 42842
|
|
|
|
|
|
|
|
| |
- Add ObjcMessageExpr::getSelector(), getClassName().
- Change Sema::getObjCInterfaceDecl() to simply take an IdentifierInfo (no Scope needed).
- Remove FIXME for printing ObjCMessageExpr's.
llvm-svn: 42543
|
|
|
|
|
|
|
|
|
|
|
|
| |
This motivated implementing a devious clattner inspired solution:-)
This approach uses a small value "Selector" class to point to an IdentifierInfo for the 0/1 case. For multi-keyword selectors, we instantiate a MultiKeywordSelector object (previously known as SelectorInfo). Now, the incremental cost for selectors is only 24,800 for Cocoa.h! This saves 156,592 bytes, or 86%!! The size reduction is also the result of getting rid of the AST slot, which was not strictly necessary (we will associate a selector with it's method using another table...most likely in Sema).
This change was critical to make now, before we have too many clients.
I still need to add some comments to the Selector class...will likely add later today/tomorrow.
llvm-svn: 42452
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is SelectorInfo is not string-oriented, it is a unique aggregate of IdentifierInfo's (using a folding set). SelectorInfo also has a richer API that simplifies the parser/action interface. 3 noteworthy benefits:
#1: It is cleaner. I never "liked" storing keyword selectors (i.e. foo:bar:baz) in the IdentifierTable.
#2: It is more space efficient. Since Cocoa keyword selectors can be quite long, this technique is space saving. For Cocoa.h, pulling the keyword selectors out saves ~180k. The cost of the SelectorInfo data is ~100k. Saves ~80k, or 43%.
#3: It results in many API simplifications. Here are some highlights:
- Removed 3 actions (ActOnKeywordMessage, ActOnUnaryMessage, & one flavor of ObjcBuildMethodDeclaration that was specific to unary messages).
- Removed 3 funky structs from DeclSpec.h (ObjcKeywordMessage, ObjcKeywordDecl, and ObjcKeywordInfo).
- Removed 2 ivars and 2 constructors from ObjCMessageExpr (fyi, this space savings has not been measured).
I am happy with the way it turned out (though it took a bit more hacking than I expected). Given the central role of selectors in ObjC, making sure this is "right" will pay dividends later.
Thanks to Chris for talking this through with me and suggesting this approach.
llvm-svn: 42395
|
|
|
|
|
|
| |
for *which* apfloat to use for a particular type.
llvm-svn: 42234
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IdentifierTable.
Rationale:
We currently have a separate table to unique ObjC selectors. Since I don't need all the instance data in IdentifierInfo, I thought this would save space (and make more sense conceptually).
It turns out the cost of having duplicate entries for unary selectors (i.e. names without colons) outweighs the cost difference between the IdentifierInfo & SelectorInfo structures. Here is the data:
Two tables:
*** Selector/Identifier Stats:
# Selectors/Identifiers: 51635
Bytes allocated: 1999824
One table:
*** Identifier Table Stats:
# Identifiers: 49500
Bytes allocated: 1990316
llvm-svn: 42139
|
|
|
|
|
|
|
|
|
|
|
| |
- Add ObjcMessageExpr AST node and associated constructors.
- Add SourceLocation's to ActOnKeywordMessage/ActOnUnaryMessage API.
- Instantiate message expressions...
- Replace alloca usage with SmallString.
Next step, installing a correct type, among other tweaks...
llvm-svn: 42116
|
|
|
|
| |
llvm-svn: 42059
|
|
|
|
|
|
|
| |
- Allow classnames as the receiver (removing a FIXME from ParseObjCMessageExpression).
- Added a FIXME to ParseObjCMessageExpression()...we need to return a message expr AST node!
llvm-svn: 42001
|
|
|
|
| |
llvm-svn: 42000
|
|
|
|
| |
llvm-svn: 41997
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 41693
|
|
|
|
|
|
|
|
| |
Array scalar initialization is now is reasonable shape.
Next step, structure and array of structure initializers.
llvm-svn: 41681
|
|
|
|
|
|
|
|
| |
- Added Expr::isConstantExpr().
- Added type checking for InitListExpr elements.
- Added diagnostic for trying to initialize a variable sized object.
llvm-svn: 41674
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Step 1: Start instantiating InitListExpr's.
Step 2: Call newly added function Sema::CheckInitializer() from Sema::ParseDeclarator().
Step 3: Give InitListExpr's a preliminary type.
Step 4: Start emitting diagnostics for simple assignments.
Note:
As a result of step 1, the CodeGen/mandel.c test asserts "Unimplemented agg expr!", which is expected.
As a result of step 4, the test below now fails. This isn't expected and needs to be investigated (it appears type checking for C++ references is flawed in some way).
******************** TEST 'Sema/cxx-references.cpp' FAILED! ********************
Command:
clang -fsyntax-only Sema/cxx-references.cpp
Output:
Sema/cxx-references.cpp:8:12: warning: incompatible pointer types assigning 'int &*' to 'int *'
int *p = &r;
^~
Sema/cxx-references.cpp:10:20: error: incompatible types assigning 'int (int)' to 'int (&)(int)'
int (&rg)(int) = g;
^
Sema/cxx-references.cpp:13:18: error: incompatible types assigning 'int [3]' to 'int (&)[3]'
int (&ra)[3] = a;
^
Sema/cxx-references.cpp:16:14: error: incompatible types assigning 'int *' to 'int *&'
int *& P = Q;
^
4 diagnostics generated.
******************** TEST 'Sema/cxx-references.cpp' FAILED! ********************
llvm-svn: 41671
|
|
|
|
| |
llvm-svn: 41653
|
|
|
|
| |
llvm-svn: 41636
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following case now works...
void empty(void * a ) {}
void test()
{
unsigned char A[4];
empty( (void *) A);
}
Thanks to Patrick Flannery for finding this...
llvm-svn: 41630
|
|
|
|
| |
llvm-svn: 41615
|
|
|
|
| |
llvm-svn: 41613
|
|
|
|
|
|
| |
to test for the right type class.
llvm-svn: 41601
|
|
|
|
| |
llvm-svn: 41582
|
|
|
|
| |
llvm-svn: 41581
|
|
|
|
|
|
|
|
| |
== or !=.
This is the same functionality gcc provides via --Wfloat-equal.
llvm-svn: 41574
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
variable argument lists).
[dylan:~/llvm/tools/clang] admin% cat x.c
int printf(const char *, ...);
int oldschool();
void foo() {
float f;
short i;
printf("foo %f", 1.0f);
oldschool(f,i);
}
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang x.c -parse-ast-dump
int printf(char const *, ...);
int oldschool();
void foo()
(CompoundStmt 0x3105f00
(DeclStmt 0x3105ba0
0x3105ce0 "float f")
(DeclStmt 0x3105c90
0x3105d10 "short i")
(CallExpr 0x3105df0 'int'
(ImplicitCastExpr 0x3105dc0 'int (*)(char const *, ...)'
(DeclRefExpr 0x3105c20 'int (char const *, ...)' Decl='printf' 0x3105bd0))
(ImplicitCastExpr 0x3105dd0 'char const *'
(StringLiteral 0x3105d60 'char *' "foo %f"))
(ImplicitCastExpr 0x3105de0 'double'
(FloatingLiteral 0x3105d80 'float' 1.000000)))
(CallExpr 0x3105ed0 'int'
(ImplicitCastExpr 0x3105ea0 'int (*)()'
(DeclRefExpr 0x3105e20 'int ()' Decl='oldschool' 0x3105c40))
(ImplicitCastExpr 0x3105eb0 'double'
(DeclRefExpr 0x3105e40 'float' Decl='f' 0x3105ce0))
(ImplicitCastExpr 0x3105ec0 'int'
(DeclRefExpr 0x3105e60 'short' Decl='i' 0x3105d10))))
llvm-svn: 41558
|
|
|
|
|
|
| |
Also removed an old FIXME (FIXME: "auto func();" passes through...).
llvm-svn: 41555
|
|
|
|
|
|
|
|
| |
Converted ParmVarDecl, FileVarDecl, BlockVarDecl, and Sema::ParseIdentifierExpr() to use the idiom.
Updated array-constraint.c to make sure we no longer get "undeclared identifier" errors:-)
llvm-svn: 41552
|
|
|
|
|
|
| |
operator.
llvm-svn: 41550
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
types.
For example, the following code was resulting in spurious warnings. This was the result of
Sema::GetTypeForDeclarator() synthesizing a type to hand back to the caller (in this case,
"int []", instead of "struct s[]", which is invalid).
struct s;
struct s* t (struct s z[]) { // expected-error {{array has incomplete element type}}
return z;
}
Strategy: Flag the error in Declarator/DeclaratorChunk. This info is later stored in
the ParmVarDecl. If the decl is referenced, Sema::ParseIdentifierExpr() will check if
the type is invalid. If so, it quietly returns "true", without instantiating a DeclRefExpr.
This seems to work nicely. If Chris is happy with the approach, I will generalize this to
all VarDecls.
llvm-svn: 41521
|
|
|
|
| |
llvm-svn: 41517
|
|
|
|
| |
llvm-svn: 41515
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changed Sema::UsualArithmeticConversions to use the new API.
This fixes the following case...
_Complex double X;
double y;
void foo() {
X = X + y;
}
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang complex.c -parse-ast-dump
Read top-level variable decl: 'X'
Read top-level variable decl: 'y'
void foo()
(CompoundStmt 0x2605cc0
(BinaryOperator 0x2605ca0 '_Complex double' '='
(DeclRefExpr 0x2605c10 '_Complex double' Decl='X' 0x2605ab0)
(BinaryOperator 0x2605c80 '_Complex double' '+'
(DeclRefExpr 0x2605c30 '_Complex double' Decl='X' 0x2605ab0)
(ImplicitCastExpr 0x2605c70 '_Complex double'
(DeclRefExpr 0x2605c50 'double' Decl='y' 0x2605ae0)))))
llvm-svn: 41483
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modified Type::typesAreCompatible() to use the above.
This fixes the following bug submitted by Keith Bauer (thanks!).
int equal(char *a, const char *b)
{
return a == b;
}
Also tweaked Sema::CheckCompareOperands() to ignore the qualifiers when
comparing two pointer types (though it doesn't relate directly to this bug).
llvm-svn: 41476
|
|
|
|
|
|
|
|
|
| |
ASTContext::getFloatingTypeOfSizeWithinDomain().
Changed Sema::UsualArithmeticConversions to correctly implement complex/float conversions,
using maxFloatingType() with getFloatingTypeOfSizeWithinDomain().
llvm-svn: 41474
|
|
|
|
|
|
| |
fixes GCC PR33193
llvm-svn: 41428
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
represent imaginary literals:
float _Complex A;
void foo() {
A = 1.0iF;
}
generates:
(BinaryOperator 0x2305ec0 '_Complex float' '='
(DeclRefExpr 0x2305e60 '_Complex float' Decl='A' 0x2305cf0)
(ImaginaryLiteral 0x2305f40 '_Complex float'
(FloatingLiteral 0x2305ea0 'float' 1.000000))))
llvm-svn: 41413
|
|
|
|
| |
llvm-svn: 41412
|
|
|
|
|
|
| |
to merge duplicate code.
llvm-svn: 41410
|
|
|
|
|
|
|
|
|
|
| |
char *C;
C != ((void*)0);
Should not warn about incompatible pointer types. Also, make sure to
insert an implicit conversion even if the operand is null.
llvm-svn: 41408
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
change
eliminates the possibility that the left hand expression is an ImplicitCastExpr.
As a result, I removed the check for ImplicitCastExpr in Expr::isLvalue().
This results in the following AST's...
[dylan:~/llvm/tools/clang] admin% cat fix.c
short x; void test4(char c) {
x += c;
x = x + c;
}
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang fix.c -parse-ast-dump
Read top-level variable decl: 'x'
void test4(char c)
(CompoundStmt 0x2605d30
(CompoundAssignOperator 0x2605c40 'short' '+='
(DeclRefExpr 0x2605c00 'short' Decl='x' 0x2605a80)
(DeclRefExpr 0x2605c20 'char' Decl='c' 0x2605bc0))
(BinaryOperator 0x2605d10 'short' '='
(DeclRefExpr 0x2605c60 'short' Decl='x' 0x2605a80)
(ImplicitCastExpr 0x2605d00 'short'
(BinaryOperator 0x2605ce0 'int' '+'
(ImplicitCastExpr 0x2605cc0 'int'
(DeclRefExpr 0x2605c80 'short' Decl='x' 0x2605a80))
(ImplicitCastExpr 0x2605cd0 'int'
(DeclRefExpr 0x2605ca0 'char' Decl='c' 0x2605bc0))))))
llvm-svn: 41404
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"assignments",
while includes init decls, assignment exprs, call exprs, and return statements.
Here are a few examples with the correct AST's...
[dylan:~/llvm/tools/clang] admin% cat impcomp.c
_Complex double X;
void test2(int c) {
X = 5;
}
void foo() {
int i;
double d = i;
double _Complex a = 5;
test2(a);
a = 5;
d = i;
}
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang impcomp.c -parse-ast-dump
Read top-level variable decl: 'X'
void test2(int c)
(CompoundStmt 0x2605ce0
(BinaryOperator 0x2605cc0 '_Complex double' '='
(DeclRefExpr 0x2605c70 '_Complex double' Decl='X' 0x2605af0)
(ImplicitCastExpr 0x2605cb0 '_Complex double'
(IntegerLiteral 0x2605c90 'int' 5))))
void foo()
(CompoundStmt 0x2606030
(DeclStmt 0x2605bd0
0x2605d90 "int i")
(DeclStmt 0x2605e20
0x2605de0 "double d =
(ImplicitCastExpr 0x2605e10 'double'
(DeclRefExpr 0x2605dc0 'int' Decl='i' 0x2605d90))")
(DeclStmt 0x2605e90
0x2605e50 "_Complex double a =
(ImplicitCastExpr 0x2605e80 '_Complex double'
(IntegerLiteral 0x2605e30 'int' 5))")
(CallExpr 0x2605f20 'void'
(ImplicitCastExpr 0x2605f00 'void (*)(int)'
(DeclRefExpr 0x2605ea0 'void (int)' Decl='test2' 0x2605c00))
(ImplicitCastExpr 0x2605f10 'int'
(DeclRefExpr 0x2605ec0 '_Complex double' Decl='a' 0x2605e50)))
(BinaryOperator 0x2605fa0 '_Complex double' '='
(DeclRefExpr 0x2605f50 '_Complex double' Decl='a' 0x2605e50)
(ImplicitCastExpr 0x2605f90 '_Complex double'
(IntegerLiteral 0x2605f70 'int' 5)))
(BinaryOperator 0x2606010 'double' '='
(DeclRefExpr 0x2605fc0 'double' Decl='d' 0x2605de0)
(ImplicitCastExpr 0x2606000 'double'
(DeclRefExpr 0x2605fe0 'int' Decl='i' 0x2605d90))))
llvm-svn: 41379
|
|
|
|
| |
llvm-svn: 41377
|
|
|
|
| |
llvm-svn: 41375
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
assignments,
it is o.k. for the LHS and RHS to have different types. Converting the type can cause
errors like the one Chris noticed (below).
This change required a fair number of diffs (since there is a lot of shared code
between single and compound assignments). This makes the API's look a bit uglier,
however I couldn't think of a better way to do it (without duplicating code).
Fix the following (incorrect) error:
int A;
long long B;
void foo() {
A /= B;
}
$ clang ~/scalar.c -emit-llvm
/Users/sabre/scalar.c:6:5: error: expression is not assignable
A /= B;
~ ^
Now it works properly...
[dylan:~/llvm/tools/clang] admin% cat compound.c
int A;
long long B;
void foo() {
A /= B;
}
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang compound.c -parse-ast-dump
Read top-level variable decl: 'A'
Read top-level variable decl: 'B'
void foo()
(CompoundStmt 0x2605c40
(BinaryOperator 0x2605c20 'int' '/=' ComputeTy='long long'
(DeclRefExpr 0x2605be0 'int' Decl='A' 0x2605a80)
(DeclRefExpr 0x2605c00 'long long' Decl='B' 0x2605ab0)))
llvm-svn: 41364
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now we emit the following when -pedantic-errors is enabled...
[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang complex.c -pedantic-errors
complex.c:4:3: error: ISO C does not support '++'/'--' on complex integer types
++x;
^ ~
complex.c:9:7: error: ISO C does not support '~' for complex conjugation
X = ~Y;
^
complex.c:10:7: error: ISO C does not support '~' for complex conjugation
x = ~y;
^
llvm-svn: 41362
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This following now compiles without error...
_Complex unsigned X, Y;
_Complex double x, y;
void test2(int c) {
X = ~Y;
x = ~y;
}
llvm-svn: 41341
|
|
|
|
| |
llvm-svn: 41340
|
|
|
|
|
|
|
|
|
|
|
| |
Now, the following test case succeeds...
_Complex double x, y;
void test2(int c) {
++x;
}
llvm-svn: 41335
|
|
|
|
| |
llvm-svn: 41273
|