<div dir="ltr"><div dir="ltr">On Tue, Jul 16, 2019 at 10:47 AM Ilya Biryukov <<a href="mailto:ibiryukov@google.com">ibiryukov@google.com</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">Thanks for pointing this out, the codegen does run on every top level declaration.<div>However, it does nothing if any errors were reported. </div><div><br></div><div>That means we could prevent codegen by:</div><div>1. emitting the diagnostics for uncorrected typos on each top-level declaration, before the codegen kick in,</div><div>2. checking if there are any "pending" typos in addition to checking for errors before doing the codegen.</div><div><br></div><div>Either should be doable. (1) has the advantage of reporting the errors earlier, making them easier to fix/diagnose.</div><div><br></div><div>However, (1) might not be a little involved. At least I got the impression from talking to various people that some typos are only fixed at template instantiation time.</div><div>The code to figure out at which point the uncorrected typos should be emitted for template instantiations might be a little involved because of this.</div><div><br></div><div>I would be surprised if the proposed assertion(!HasErrors || Typos.empty()) ever fired in practice. It's rare to see only a single compiler error coming from clang, so I would expect almost any typo to induce at least another error right away. That's actually why I'd expect the "broken codegen" to be hardly possible in practice.</div><div><br></div><div>Out of the options we have, I'll probably add checks for (2) to codegen and emit the delayed typos at the end of TU. That seems to be the simplest option, at least.</div><div>Happy to go with (1) or the alternative assertion if people think the proposed approach would lead to too many diagnostics.</div></div></blockquote><div><br></div><div>I think what you said about template instantiation means we can't do 2, but I might not understand how the system works. What I had in mind was making clang assert (or making sure it already does) when trying to codegen TypoExpr. I see TypoExpr has no hits in clang/lib/CodeGen. It might already, though, in which case I don't think we need to do anything more than the end-of-tu diagnosis.</div></div></div>