<div dir="ltr"><div>We also don't have the capacity to completely redesign the typo correction, so ensuring it (1) does not crash us and (2) produces diagnostics without typo-correction looks like a reasonable short-term fix.</div><div>I will look into emitting the diagnostics emitted instead of asserting.</div><div><br></div><div>Thanks for the input!<br><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 16, 2019 at 12:49 PM Sam McCall <<a href="mailto:sammccall@google.com">sammccall@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Thanks for starting this discussion, this does need a systematic fix.</div><div dir="ltr"><br></div><div dir="ltr">On Mon, Jul 15, 2019 at 8:19 PM Ilya Biryukov via clangd-dev <<a href="mailto:clangd-dev@lists.llvm.org" target="_blank">clangd-dev@lists.llvm.org</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>We would like to avoid assertion failures for those, which leads me to the following questions:</div><div>- Is there a way to quickly track down the place that miss the CorrectDelayedTypos* call?</div></div></blockquote><div>A common pattern is that an error causes an Expr subtree to be discarded, and the code that does so "forgets" to call CorrectDelayedTypos.</div><div>e.g. <a href="https://reviews.llvm.org/rL366200" target="_blank">https://reviews.llvm.org/rL366200</a></div><div>There's usually a diagnostic emitted before the Expr is discarded, so in these cases poking around the diag emit location often sheds light. But my fear is there are tens or hundreds of these bugs, and it's hard to enumerate them.</div><div><br></div><div>At some level, this seems silly - if the Expr doesn't survive, its typos don't need to be corrected to protect CodeGen from them. The diagnostics are probably important though.</div><div>If we could ensure the diagnostics are emitted as Reid says, and reduce the requirement to be that Exprs that survive parsing get typo-corrected, then this might be tractable.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- If no, would it be ok to turn this assertion into some kind of debug-only warning and </div><div>  document that some typos are never actually corrected due to limitations?</div><div>- Even broader, are there any ideas for an alternative design that would be more resilient to</div><div>  changes in the codebase? </div><div>  E.g. no delayed typo corrections or easy-to-audit places that should run CorrectDelayedTypos*, etc.</div><div><br></div><div>-- <br></div><div><div dir="ltr" class="gmail-m_44375025765573424gmail-m_-8439188080183440163gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Regards,</div><div>Ilya Biryukov</div></div></div></div></div></div></div>
_______________________________________________<br>
clangd-dev mailing list<br>
<a href="mailto:clangd-dev@lists.llvm.org" target="_blank">clangd-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev</a><br>
</blockquote></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Regards,</div><div>Ilya Biryukov</div></div></div></div></div>