<div dir="ltr"><div dir="ltr">On Tue, Jul 16, 2019 at 10:18 AM David Blaikie via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></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">End of the TU sounds too late to me - IR generation is done incrementally (at the end of functions, for instance - though I'm not sure that's the only point), so leaving typos in until the end of the TU could lead to the "IR generation getting weird because of pending typo corrections" issue, no?</div></blockquote><div><br></div><div>Well, we currently assert in ~Sema, which is after the end of the TU, so if we hit today's assert, we've already done incremental codegen without crashing. Diagnosing at end of TU doesn't make the situation worse. The way I understand clang's incremental codegen strategy, we generate code after every top level decl. We sometimes skip incremental codegen if errors have been reported or if a Decl is invalid. I think it's a bug if an error hasn't been reported but a delayed typo expr gets sent to codegen, and we should add asserts to defend against that.</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 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 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 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 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></div></blockquote></div></blockquote></div></blockquote><div><br></div><div>

Another idea is to weaken the assert to validate that either errors have been reported, or there are no delayed typos. That would mean it's OK to forget to diagnose typos if parts of the AST are invalid, since we expect the user to fix their code and recompile, potentially discovering the typo on the next compile.</div></div></div>