[cfe-dev] [RFC] A C++ pseudo parser for tooling

[André Pönitz via cfe-dev]

On Tue, Nov 09, 2021 at 02:40:40AM +0000, Andrew Tomazos via cfe-dev wrote:
>    * Syntax highlighting is the only use case of those listed that can
>    tolerate inaccuracy.  For the rest, a correct parse will be more
>    productive.  The trouble is that if people start depending on these
>    features in their workflow, when they fail (and they often will) it will
>    be very disruptive.  The cost of the disruption outweighs the time saved
>    waiting for a correct parse.

I am afraid I don't quite agree.

I believe what is tolerable to whom under which circumstances is subjective:
Whether a correct parse is more productive will in general depend on how
much time is saved in total by the inexact parses and how much trouble a
disruption causes in an actual incident. This in turn will depend both on
the code and the individual handling the code, etc.

>    * I think you are better off spending your time on optimizing the correct
>    parser infrastructure.  I'm sure more can be done - particularly in terms
>    of caching, persisting and resusing state (think like PCH and modules
>    etc).

What if that ideal "correct" parser infrastructure does not really exist?

(a) A translation unit can contain code that can take practically
arbitrarily long to be parsed correctly. While "a few seconds" might be
tolerable in some cases for a single unit, "a few minutes" is probably
getting into the "not acceptable" range for most practical cases.

And then people might want to use that "while editing" - i.e. each keystroke
might invalidate any parse result and would need to trigger a re-parse.

(b) Not every piece of code people handle as C++ is in fact standard C++
or completely understood by Clang for that matter - think (non-Clang)
compiler extensions.  Still it would be beneficial to use Clang based
tooling on a "best effort" base. I am pretty sure in most cases I'd be
happy enough to e.g. use some automated refactoring that catches 99% of
the cases and leaves only the remaining percent for manual fixing than to
do all 100% manually.

Andre'