On Mon, Jul 14, 2014 at 4:55 PM, Kaelyn Takata <[email protected]> wrote:
> > Also be more proactive about checking a correction's visibility so that > a correction requiring a module import can be distinguished from the > original typo even if it looks identical. Otherwise the correction will > be excluded and the diagnostic about needing the module import won't be > emitted. > > Note that no change was made to checkCorrectionVisibility other than > moving where it is at in SemaLookup.cpp. > 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. 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). + if (MatchesTypo(candidate)) + return false; When does this happen?
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
