FunctionType! I didn't realize it was available, until rjmccall
pointed out that DeclaratorDecl made the typeloc available. This
makes FunctionDecl recursion *much* easier, because the typeloc can
take care of default parameters, so we no longer have to do that
separately, which means we can just do a normal type traversal instead
of this special-case WalkUp stuff we did before.
The only downside -- and it's minor -- is that because the TypeLoc
handles both the return type and the argument types, we can't recurse
on the explicit template args in the right place (which would be
between them). I do it beforehand instead. So for
int MyFunc<float>(char x);
we get callbacks in the order: float, int, char.
Reviewed by chandlerc
llvm-svn: 116945
As far as I can see, gcc is right to think this! The following change
will cause a nice segfault rather than undefined behaviour if this case
occurs. Someone who understands what this code is supposed to do should
probably take a proper look.
llvm-svn: 116917
don't repeatedly loop through identifiers, correcting the same typo'd
identifier over and over again.
We still bail out after 20 typo corrections, but this should help
improve performance in the common case where we're typo-correcting
because the user forgot to include a header.
llvm-svn: 116901
Here's example code:
---
template<class T> class MyClass {
struct S { };
S* NewS() { return new S; }
void DeleteS() { delete NewS(); }
};
---
CXXDeleteExpr::getDestroyedType() on the 'delete NewS()' expression
would crash before this change. Now it returns a dependent type
object. Solution suggested by dgregor.
llvm-svn: 116891
Now MICache is a linked list (per the FIXME), where we tradeoff between MacroInfo objects being in MICache
and MIChainHead. MacroInfo objects in the MICache chain are already "Destroy()'ed", so they can be reused. When
inserting into MICache, we need to remove them from the regular linked list so that they aren't destroyed more than
once.
llvm-svn: 116869
The problem was not the management of MacroInfo objects, but that when we recycle them
via the MICache the memory of the underlying SmallVector (within MacroInfo) was not getting
released. This is because objects stashed into MICache simply are reused with a placement
new, and never have their destructor called.
llvm-svn: 116862
computation to compute the lower bound of the edit distance, so that
we can avoid computing the edit distance for names that will clearly
be rejected later. Since edit distance is such an expensive algorithm
(M x N), this leads to a 7.5x speedup when correcting NSstring ->
NSString in the presence of a Cocoa PCH.
llvm-svn: 116849
list of allocated MacroInfos. This requires only 1 extra pointer per MacroInfo object, and allows us to blow them
away in one place. This fixes an elusive memory leak with MacroInfos (whose exact location I couldn't still figure
out despite substantial digging).
Fixes <rdar://problem/8361834>.
llvm-svn: 116842
within a default argument), recurse into default arguments. Fixes
PR8401, a regression I introduced in r113700 while refactoring our
handling of "used" declarations in default arguments.
llvm-svn: 116817
'../lib/clang/<version>'. Actually use '..' rather than removing the trailing
component to correctly handle paths containing '.' or symlinks in the presence
of -no-canonical-prefixes, etc. This shouldn't change any existing behavior.
llvm-svn: 116803
Ted Kremenek