[cfe-commits] PATCH: Add support for C++ namespace-aware typo correcting
rikka at google.com
Mon Jun 20 09:35:28 PDT 2011
Don't quite have it ready yet. Being sick for much of last week didn't
I could post for submission my last patch + the smaller cleanups that I
already have done and finish up the work as a second patch, so that folks
can get started on the serialization, etc.
On Sun, Jun 19, 2011 at 1:01 AM, Chandler Carruth <chandlerc at google.com>wrote:
> Hey, any chance you can post the latest version of you're patch? I'm
> interested in getting it checked on in. I have some time, and can work w/
> dgregor and others to wrap up the serialization and benchmarking, etc.
> On Fri, Jun 10, 2011 at 10:36 AM, Kaelyn Uhrain <rikka at google.com> wrote:
>> On Thu, Jun 9, 2011 at 6:34 PM, Chandler Carruth <chandlerc at google.com>wrote:
>>> On Thu, Jun 9, 2011 at 6:18 PM, Kaelyn Uhrain <rikka at google.com> wrote:
>>>> Quick question about doing this: would it be more cost effective to use
>>>> a std::multimap to allow iterating through the namespaces in ascending order
>>>> of NNS length and exiting the loop once NNS length + edit distance are worse
>>>> than the best, or to use an llvm::SmallVector instead and always looping
>>>> over all of the namespaces, but skipping the lookup if (NNS length + ED) is
>>>> too long?
>>> Iterating over a std::map or std::multimap is rather slow. Why can't we
>>> just keep the SmallVector sorted by the NNS length?
>> I had a feeling that was the case. The issue I'm having is in sorting the
>> NNSes by length--they vary based on the context of the typo correction, plus
>> the NNS, its length, and the DeclContext it points to have to remain
>> associated. Right now the list of known namespaces is a simple SmallPtrSet,
>> and the NNS and its length are calculated when needed--between when a symbol
>> is successfully looked up in a given DeclContext and when it is added with
>> its qualifier to the TypoCorrectionConsumer--and cached in a std::map for
>> the duration of the call to CorrectTypo (for use with other identifiers in
>> the same DeclContext). I'm not sure how the cost of calculating the
>> NestedNameSpecifiers for every namespace is affected by PCH files, but I'm
>> guessing the cost is less than what is saved by avoiding lookups in
>> namespaces stored in PCH files.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits