[cfe-dev] [clangd-dev] Delayed typo correction is fragile

[Reid Kleckner via cfe-dev]

On Tue, Jul 16, 2019 at 10:47 AM Ilya Biryukov <ibiryukov at google.com> wrote:

> Thanks for pointing this out, the codegen does run on every top level
> declaration.
> However, it does nothing if any errors were reported.
>
> That means we could prevent codegen by:
> 1. emitting the diagnostics for uncorrected typos on each top-level
> declaration, before the codegen kick in,
> 2. checking if there are any "pending" typos in addition to checking for
> errors before doing the codegen.
>
> Either should be doable. (1) has the advantage of reporting the errors
> earlier, making them easier to fix/diagnose.
>
> 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.
> 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.
>
> 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.
>
> 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.
> Happy to go with (1) or the alternative assertion if people think the
> proposed approach would lead to too many diagnostics.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190716/fe4870b9/attachment.html>