[PATCH] D47341: [Sema] Disable creating new delayed typos while correcting existing.

Volodymyr Sapsai via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri May 25 19:20:35 PDT 2018

vsapsai planned changes to this revision.
vsapsai added a comment.

After looking into this more, I think there are 2 different bugs: one with infinite loop and another with `DelayedTypos.empty() && "Uncorrected typos!"` assertion. And disabling typo correction happened to fix both of them.

Infinite loop seems to be avoidable by not using ~0U as the guard value, need to investigate further.

And uncorrected dangling delayed typo bug has a different cause. When we are checking potential corrections, we have roughly the following behaviour

  1. structVarTypo -> structVar; structVarTypo2 -> structVar;
       after correction discover more typos
       fieldNameTypo -> fieldName; fieldNameTypo2 -> fieldName;  // Overall correction fails but newly discovered typos are processed and removed.
  2. structVarTypo -> <empty correction>; structVarTypo2 -> structVar;
       correction fails early, don't discover more typos
  3. structVarTypo -> structVar; structVarTypo2 -> <empty correction>;
       correction fails but we discover fieldNameTypo and the way correction fails we don't attempt to correct this new delayed typo
  4. structVarTypo -> <empty correction>; structVarTypo2 -> <empty correction>;
       correction fails early, don't discover more typos

So the typo from step 3 is the one that remains till ~Sema.

I've spent some time looking into Richard's suggestion to correct typos immediately. That gets more involved than I expected and I want to finish investigating my other ideas. Now I think that my original approach with disabling typo correction just hides the issue instead of fixing it. And I feel like immediate typo correction can be hiding the actual issue too but it is too early to say.


More information about the cfe-commits mailing list