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

Sam McCall via cfe-dev cfe-dev at lists.llvm.org
Tue Jul 16 03:49:14 PDT 2019


Thanks for starting this discussion, this does need a systematic fix.

On Mon, Jul 15, 2019 at 8:19 PM Ilya Biryukov via clangd-dev <
clangd-dev at lists.llvm.org> wrote:

> We would like to avoid assertion failures for those, which leads me to the
> following questions:
> - Is there a way to quickly track down the place that miss the
> CorrectDelayedTypos* call?
>
A common pattern is that an error causes an Expr subtree to be discarded,
and the code that does so "forgets" to call CorrectDelayedTypos.
e.g. https://reviews.llvm.org/rL366200
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.

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.
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.


> - If no, would it be ok to turn this assertion into some kind of
> debug-only warning and
>   document that some typos are never actually corrected due to limitations?
> - Even broader, are there any ideas for an alternative design that would
> be more resilient to
>   changes in the codebase?
>   E.g. no delayed typo corrections or easy-to-audit places that should run
> CorrectDelayedTypos*, etc.
>
> --
> Regards,
> Ilya Biryukov
> _______________________________________________
> clangd-dev mailing list
> clangd-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190716/d1ffac77/attachment.html>


More information about the cfe-dev mailing list