Endless loop in Sema::CorrectTypo

Hi Yaron

I tried your sample file out on my machine with libcxx tot and clang tot. I should note my libcxx has some patches in that are waiting to be applied, so it’s not quite like yours, but hopefully that won’t make a difference.

Your example took about 14 seconds to compile on my machine. That time is excessive. g++ produced a similar error instantly.

I’ve report other excessive compile times recently and this may or may not be related. See this bug for a similar slow example:
http://llvm.org/bugs/show_bug.cgi?id=17414

Something is definitely wrong, that something could be more than one thing.

clang was stuck for at least 3 minutes on my machine, but it’s a slow i3 and I use clang build with assertions on which slow the compilation. In any case, without the zzzzzzzzzzzz error it takes about 3 seconds (not too fast either) and clang should not behave like that. Previous r191323 did not.

I run clang under debugger and breaked clang a few times it was always in Sema::CorrectTypo or its called functions so something is likely wrong with it, clang tries “too hard” to correct the error.

Yaron

FYI, I'm working on speeding up CorrectTypo as it seems to be causing
long compile times (sometimes effectively infinite; e.g. one hour
churning on a single TU before killing clang) in large TUs with lots
of classes particularly when there are unknown identifiers. From what
I can tell, the problem is that it is too thorough, trying to look up
almost every known identifier in every class and namespace even if the
identifier is almost totally different from the original typo... and
CorrectTypo is called in cases that aren't guaranteed to be errors.

I have a patch that removes very unlikely correction candidates from
the pool before any lookups are performed on them, but right now it
breaks the 9 altivec tests because typo correction is attempted and
fails on all the uses of the altivec-specific "vector" type
specifier--they pass without my patch due to an unintentional
side-effect of CorrectTypo's current behavior (and it is very fragile
since it depends on CorrectTypo trying too hard to find a correction
that is then discarded late in CorrectTypo).

Cheers,
Kaelyn