[cfe-commits] r148720 - in /cfe/trunk: lib/Sema/SemaLookup.cpp test/SemaCXX/typo-correction.cpp

[Kaelyn Uhrain]

On Mon, Jan 23, 2012 at 2:05 PM, Chandler Carruth <chandlerc at google.com>wrote:

> On Mon, Jan 23, 2012 at 12:18 PM, Kaelyn Uhrain <rikka at google.com> wrote:
>
>> Author: rikka
>> Date: Mon Jan 23 14:18:59 2012
>> New Revision: 148720
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=148720&view=rev
>> Log:
>> In CorrectTypo, use the cached correction as a starting point instead.
>>
>> Previously, for unqualified lookups, a positive cache hit is used as the
>> only non-keyword correction and a negative cache hit immediately returns
>> an empty TypoCorrection. With the new callback objects, this behavior
>> causes false negatives by not accounting for the fact that callback
>> objects alter the set of potential/allowed corrections. The new behavior
>> is to seed the set of corrections with the cached correction (for
>> positive hits) to estabilishing a baseline edit distance. Negative cache
>> hits are only stored or used when either no callback object is provided
>> or when it returns true for a call to ValidateCandidate with an empty
>> TypoCorrection (i.e. when ValidateCandidate does not seem to be doing
>> any checking of the TypoCorrection, such as when an instance of the base
>> callback class is used solely to specify the set of keywords to be
>> accepted).
>>
>
> Is there any performance impact to this change? It seems like it would
> make the caching much less effective. Is that acceptable for all of the
> correction clients?
>

I haven't tested it, but I suspect the performance impact is fairly minimal
in most cases--the same typo would have to be repeated many many times
within the same translation unit for caching to yield much benefit, and
even then only if the cached correction actually works in (almost) every
case instead of triggering cascading errors. Plus there were already other
issues with the caching that have been accumulating as CorrectTypo has
become more sophisticated, since there had not been any checks on the
cached correction e.g. to make sure it is actually reachable in the current
location. If the one extreme case is enough of a concern, I can extend the
stop gap for when there are more than 20 unqualified typos corrected to not
continue with the normal correction path if a given typo was found in the
correction cache (I just noticed that I broke the stop-gap in certain cases
when I added the callback objects and changed the code to only return the
cached correction if it passes validation).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120123/581ba456/attachment.html>