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

[Ilya Biryukov via cfe-dev]

https://reviews.llvm.org/D64799 removes the assertion and emits diagnostics
at the end of the TU.

On Tue, Jul 16, 2019 at 4:11 PM Ilya Biryukov <ibiryukov at google.com> wrote:

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


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