<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 14, 2014 at 4:55 PM, Kaelyn Takata <span dir="ltr"><<a href="mailto:rikka@google.com" target="_blank">rikka@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"><br>
Also be more proactive about checking a correction's visibility so that<br>
a correction requiring a module import can be distinguished from the<br>
original typo even if it looks identical. Otherwise the correction will<br>
be excluded and the diagnostic about needing the module import won't be<br>
emitted.<br>
<br>
Note that no change was made to checkCorrectionVisibility other than<br>
moving where it is at in SemaLookup.cpp. <br></blockquote></div><br></div><div class="gmail_extra">Perhaps I'm missing the trick here (since there are no tests as part of this change, it's not easy to see exactly how this pans out), but I don't see how we're producing the missing import diagnostic along the delayed typo correction codepath in a way that doesn't cause typo correction to fail.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">That said, I don't think we need to do so (and perhaps this is how this already works out): if we can resolve the "typo" with a module import, we can correct it on the fly and never build a TypoExpr. If we actually need to correct the typo, then we never need to add a module import (because we never consider typo-correcting to a non-visible name).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">+  if (MatchesTypo(candidate))</div><div class="gmail_extra">+    return false;</div><div><br></div><div>
When does this happen?</div></div></div>