[LTP] [PATCH 0/7] docparse improvements

[Richard Palethorpe]

Hello Cryil,

Cyril Hrubis <chrubis@suse.cz> writes:

> Hi!
>> It's incredibly fast, it has no trouble parsing the entire kernel.
>> 
>> Weggli uses tree-sitter
>> 
>> https://github.com/googleprojectzero/weggli
>> ________________________________________________________
>> Executed in   49.35 millis    fish           external
>>    usr time  110.88 millis    0.00 millis  110.88 millis
>>    sys time   87.44 millis    1.20 millis   86.24 millis
>
> This looks like it's about the speed of grep, that sounds incredible.
>
>> > Well I would say that this patchset is the last addition for the parser,
>> > if we ever need anything more complex we should really switch to
>> > something else. On the other hand I do not think that we will ever need
>> > more complexity in the parser than this, as long as we keep things
>> > sane.
>> 
>> This closes the door on a lot of options for no upside AFAICT. We have
>> two tools (Sparse and tree-sitter) that can be (or have been) vendored
>> and will parse a large subset of C. Sparse goes a step further allowing
>> control flow analysis. The usual reasons for reinventing the wheel are
>> not present.
>
> Still working on a prototype based on tree-sitter would take a week or
> two worth of time and I would like to get the metadata fixed now, so
> that I can finally move on with runltp-ng. So I would slightly prefer
> merging the patches for the current solution first, then we can have a
> look on tree-sitter in the next LTP release cycle. What do you think?

I think there is a small risk

1. It turns out that with tree-sitter it would make more sense to use a
   different meta-data format.
2. Someone starts building on the current solution without realising it
   might change

Of course this can be mitigated by saying that the implementation and
format are subject to change.

Note that in general I think it's best (on bigger projects) to have an
alternative branch for big changes where one needs to "rush" to an
end-to-end solution. Most likely we need an alternate branch for
integrating runltp-ng and the executor.

-- 
Thank you,
Richard.