[cfe-commits] PATCH: Add support for C++ namespace-aware typo correcting

Chandler Carruth chandlerc at google.com
Sun Jun 19 01:01:24 PDT 2011

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...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110619/a2f0e59e/attachment.html>

More information about the cfe-commits mailing list