<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jul 25, 2014 at 3:03 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=richard@metafoo.co.uk&cc=&bcc=&su=&body=','_blank');return false;" class="cremed">richard@metafoo.co.uk</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"><div><div>+  if (TE && SemaRef.getLangOpts().CPlusPlus) {</div>
<div>+    // TODO: C cannot handle TypoExpr nodes because the C code paths do not know</div><div>+    // what to do with dependent types e.g. on the LHS of an assigment.</div>
</div><div>+    *TE = SemaRef.CorrectTypoDelayed(<br></div><div><br></div><div>Does this recover correctly if CorrectTypoDelayed returns nullptr? I'd have expected that you should carry on and produce an error in this case.</div>
</div></blockquote><div><br></div><div>Yes it does in that the behavior of LookupMemberExprInRecord when CorrectTypoDelayed returns nullptr is identical to the behavior of when CorrectTypo fails: LookupMemberExprInRecord returns false and LookupMemberExpr returns an ExprResult containing a nullptr. In both cases, the final recovery is based on the LookupResult having been cleared. </div>
<div><br></div><div>I've dropped the superfluous ?: in LookupMemberExpr and expanded the existing comment to include a description of the error case since the comment had just said that returning valid-but-null meant the LookupResult was filled in.</div>
<div> </div><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">
<div><br></div><div>+        SemaRef.AddMethodCandidate(</div><div>+            DeclAccessPair::make(ND, AS_none), BaseType.getNonReferenceType(),</div><div>+            /*MemberRef.get()->Classify(SemaRef.Context)*/Expr::Classification::makeSimpleLValue(), Args, CandidateSet);</div>

<div><br></div><div>Commented-out code?</div></div></blockquote><div><br></div><div>Whoops! Thanks. </div><div><br></div><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"><div><br></div><div><div>+      // Perform overload resolution.</div><div>+      OverloadCandidateSet::iterator Best;</div><div>+      auto result = CandidateSet.BestViableFunction(</div>
<div>+          SemaRef, CE->getLocStart(), Best);</div></div><div><br></div><div>Do you need to do this here? Can you instead simply build an unresolved overload set and allow the TreeTransform to do overload resolution when it transforms the parent, or is there some subtlety that makes this necessary?</div>
</div></blockquote><div><br></div><div>Yes the resolution has to be done here. The "subtlety" is that letting the call to BuildMemberReferenceExpr return an UnresolvedMemberExpr when the parent expr is a CallExpr leads to incorrect diagnostic notes, e.g. from typo-correction-pt2.cpp:</div>
<div><br></div><div><div>namespace PR13387 {</div><div>struct A {</div><div>  void CreateFoo(float, float);</div><div>  void CreateBar(float, float);</div><div>};</div><div>struct B : A {</div><div>  using A::CreateFoo;</div>
<div>  void CreateFoo(int, int);  // expected-note {{'CreateFoo' declared here}}</div><div>};</div><div>void f(B &x) {</div><div>  x.Createfoo(0,0);  // expected-error {{no member named 'Createfoo' in 'PR13387::B'; did you mean 'CreateFoo'?}}</div>
<div>}</div><div>}</div></div><div><br></div><div>Without the overload resolution, the note for CreateFoo points to the wrong CreateFoo (it ends up pointing to the first member with that name):</div><div><br></div><div><div>
test/SemaCXX/typo-correction-pt2.cpp:26:8: note: 'CreateFoo' declared here</div><div>  void CreateFoo(float, float);</div></div><div><br></div><div>With the overload resolution, the note points to the correct Createfoo:</div>
<div><br></div><div><div>test/SemaCXX/typo-correction-pt2.cpp:31:8: note: 'CreateFoo' declared here</div><div>  void CreateFoo(int, int);  // expected-note {{'CreateFoo' declared here}}</div></div><div><br>
</div><div>I've added a comment explaining why the overload resolution is being performed here.</div><div><br></div><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">
<div><br></div><div><br></div><div><div>+  something(obj.toobat,   // expected-error {{did you mean 'foobar'?}}</div><div>+            obj.toobat);  // expected-error {{did you mean 'toobad'?}}</div></div>

<div><br></div><div>I love this testcase =)</div></div></blockquote><div><br></div><div>^_^ </div><div><br></div><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 class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Mon, Jul 14, 2014 at 4:55 PM, Kaelyn Takata <span dir="ltr"><<a href="mailto:rikka@google.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=rikka@google.com&cc=&bcc=&su=&body=','_blank');return false;" class="cremed">rikka@google.com</a>></span> wrote:<br>

</div></div><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><div class="h5"><br>
This includes adding the new TypoExpr-based lazy typo correction to<br>
LookupMemberExprInRecord as an alternative to the existing eager typo<br>
correction.<br>
---<br>
 lib/Sema/SemaExprMember.cpp              | 149 +++++++++++++++++++++++++++++--<br>
 test/SemaCXX/arrow-operator.cpp          |   5 +-<br>
 test/SemaCXX/typo-correction-delayed.cpp |  32 +++++++<br>
 test/SemaCXX/typo-correction-pt2.cpp     |   2 +-<br>
 test/SemaCXX/typo-correction.cpp         |  10 +--<br>
 5 files changed, 182 insertions(+), 16 deletions(-)<br>
 create mode 100644 test/SemaCXX/typo-correction-delayed.cpp<br>
<br>
<br></div></div>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank" 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>
</blockquote></div><br></div></div>