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

[Ilya Biryukov via cfe-dev]

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.
I will look into emitting the diagnostics emitted instead of asserting.

Thanks for the input!


On Tue, Jul 16, 2019 at 12:49 PM Sam McCall <sammccall at google.com> wrote:

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

-- 
Regards,
Ilya Biryukov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190716/88cc5ec8/attachment.html>