Moved utility functions IgnoreParen and friends to be static inline functions
defined in SemaUtil.h.
Added SemaUtil.h to Xcode project.
llvm-svn: 44312
backing a rewrite buffer than using an std::vector<char>. This class was hacked
together very quickly and needs to be cleaned up, but it seems to work. It speeds
up rewriting a a 7M file from 6.43s to 0.24s on my machine. The impl could also
be made to be a lot more algorithmically sound.
This produces identical output to using vector on this testcase, if it causes a
problems or bugs are encountered, it can be disabled by changing the
RewriteBuffer::Buffer typedef back.
llvm-svn: 43884
This removes several gross hacks to work around the previous "lazy" behavior.
Two notes:
- MinimalActions still needs to be taught about the built-in types (This breaks one of the -noop test cases). I started this, then added a FIXME.
- I didn't convert Sema::GetObjcProtoType() yet.
llvm-svn: 43567
I didn't realize that GCC considers this a hard error (I thought it was built-in).
Since it's not, we should simply emit an error.
[dylan:~/llvm/tools/clang] admin% cc -c trivial.m
trivial.m:6: error: cannot find interface declaration for 'NSConstantString'
[administrators-powerbook59:~/llvm/tools/clang] admin% ../../Debug/bin/clang trivial.m
trivial.m:6:16: error: cannot find interface declaration for 'NSConstantString'
NSString *s = @"123";
^
1 diagnostic generated.
llvm-svn: 43157
unsigned char asso_values[] = { 34 };
int legal2() {
return asso_values[0];
}
The code that creates the new constant array type was operating on the original type.
As a result, the constant type being generated was "unsigned char [1][]" (which is wrong).
The fix is to operate on the element type - in this case, the correct type is "unsigned char [1]"
I added this case to array-init.c, which clearly didn't catch this bogosity...
llvm-svn: 43112
Rename SourceRange::Begin()/End() to getBegin()/getEnd() for
consistency with other code.
Start building the rewriter towards handling @encode.
llvm-svn: 43047
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
Ted Kremenek