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

[David Blaikie via cfe-dev]

End of the TU sounds too late to me - IR generation is done incrementally
(at the end of functions, for instance - though I'm not sure that's the
only point), so leaving typos in until the end of the TU could lead to the
"IR generation getting weird because of pending typo corrections" issue, no?

On Tue, Jul 16, 2019 at 8:04 AM Ilya Biryukov via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 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
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190716/a9b6d92f/attachment.html>