<div dir="ltr">The patch looks good to me for the most part. One thing you may want to try though: the TypoCorrection *should* already contain all of the NamedDecls needed for overload resolution (TypeCorrection::getCorrectionDecl just returns the first NamedDecl if there are any associated with the TypoCorrection, i.e. the correction is for an existing declaration and is not a keyword), so you ought to be able to avoid the additional name lookup by doing:<div>
<br></div><div>for (TypoCorrection::decl_iterator DI = Corrected.begin(), DIEnd = Corrected.end(); DI != DIEnd; ++DI) {</div><div>  R.addDecl(*DI);</div><div>}</div><div><br></div><div>instead of calling "SemaRef.LookupQualifiedName(R, DC);"... that the function was only adding the first NamedDecl to the LookupResult instead of all of them was because I missed it when I improved the handling of typo corrections in the presence of overloaded names.</div>
<div><br></div><div style>And one important difference I thought of while writing the above: although it probably doesn't affect LookupMemberExprInRecord right now since member lookups occur before the function call information is available, the NamedDecls in the TypoCorrection object would not necessarily be the same set returned by LookupQualifiedName... they would have been filtered by the CorrectionCandidateCallback object passed to CorrectTypo, reducing the work that the overload resolution would have to do later and possibly avoiding it altogether if the callback has enough information to exclude all but one candidate. Calling LookupQualifiedName could lead to overload resolution being done because it found multiple NamedDecls even when CorrectTypo returned a correction with a single NamedDecl. Also, the TypoCorrection may include a NestedNameSpecifier that is needed for the the name to be visible from the given DeclContext (the "DC" variable), and in those situations the call to LookupQualifiedName on the correction's DeclarationName would fail.</div>
<div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 8, 2013 at 4:35 PM, Nick Lewycky <span dir="ltr"><<a href="mailto:nlewycky@google.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=nlewycky@google.com&cc=&bcc=&su=&body=','_blank');return false;" class="cremed">nlewycky@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">The problem is best explained with a testcase:<div>
<br></div><div><div>struct A {};</div><div>struct B {};</div><div><br></div><div>struct S {</div><div>  void method(A*);</div><div>  void method(B*);</div><div>

};</div><div><br></div><div>void test() {</div><div>  B b;</div><div>  S s;</div><div>  s.methodd(&b);</div><div>}</div></div><div><br></div><div>we currently typo-correct the "s.methodd" to "s.method" but refer to the NamedDecl* for "void method(A*);" both in the note and when continuing to parse. That in turn causes an extra diagnostics (can't convert B* to A*), but worse in my mind is the fact that the parser isn't recovering as though the suggested replacement text were applied.</div>


<div><br></div><div>Patch attached, now we recover by returning a LookupResult with all the overload candidates found by looking up the typo-corrected name, and we don't emit the note pointing to the previous decl(s) in case of overloaded results. Please review closely, I'm not very familiar with this part of clang.</div>
<span class=""><font color="#888888">

<div><br></div><div>Nick</div><div><br></div></font></span></div>
<br>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=cfe-commits@cs.uiuc.edu&cc=&bcc=&su=&body=','_blank');return false;" class="cremed">cfe-commits@cs.uiuc.edu</a><br>

<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank" class="cremed">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
<br></blockquote></div><br></div></div></div>