over is the subexpression of a sizeof(expression). Different clients
will wish to handle iteration over such subexpressions differently, and can
now easily query if they are iterating over such statements using the
StmtIterator's inSizeOfExpr().
llvm-svn: 45047
declared in a sizeof. For example:
sizeof(int[foo()]);
the expression "foo()" is an expression that is executed during the evaluation
of sizeof.
llvm-svn: 45043
Moved all clients of Diagnostics to use FullSourceLoc instead of SourceLocation.
Added many utility methods to FullSourceLoc to provide shorthand for:
FullLoc.getManager().someMethod(FullLoc.getLocation());
instead we have:
FullLoc.someMethod();
Modified TextDiagnostics (and related classes) to use this short-hand.
llvm-svn: 44957
visits its decls, rather than just creating an "end()" iterator.
Fixed child_end() for statements and expressions to use
child_iterator() to create the end() iterator, rather than just
returning NULL.
Fixed bug in StmtIterator where we did not correctly detect if we had
marched off the end of the ScopedDecls.
llvm-svn: 43156
This allowed me to fix the following hack from this weekend...
// FIXME: Devise a way to do this without using strcmp.
// Would like to say..."return getAsStructureType() == IdStructType;", but
// we don't have a pointer to ASTContext.
bool Type::isObjcIdType() const {
if (const RecordType *RT = getAsStructureType())
return !strcmp(RT->getDecl()->getName(), "objc_object");
return false;
}
...which is now...
bool isObjcIdType(QualType T) const {
return T->getAsStructureType() == IdStructType;
}
Side notes:
- I had to remove a convenience function from the TypesCompatibleExpr class.
int typesAreCompatible() const {return Type::typesAreCompatible(Type1,Type2);}
Which required a couple clients get a little more verbose...
- Result = TCE->typesAreCompatible();
+ Result = Ctx.typesAreCompatible(TCE->getArgType1(), TCE->getArgType2());
Overall, I think this change also makes sense for a couple reasons...
1) Since ASTContext vends types, it makes sense for the type compatibility API to be there.
2) This allows the type compatibility predeciates to refer to data not strictly present in the AST (which I have found problematic on several occasions).
llvm-svn: 43009
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
#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
integer constant expressions. The only questionable
thing is that we now reject:
void foo() {
switch (1) {
case (int)1.0e10000:
;
}
}
with:
t.c:5:13: error: case label does not reduce to an integer constant
case (int)1.0e10000:
~~~~~^~~~~~~~~
GCC accepts this, emitting the pedwarn:
t.c:5: warning: floating constant exceeds range of 'double'
llvm-svn: 42238
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
