<div dir="ltr"><div dir="ltr">On Tue, Nov 9, 2021 at 4:38 PM Demi Marie Obenour via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>> * I think you are better off spending your time on optimizing the correct<br>
>> parser infrastructure.  I'm sure more can be done - particularly in terms<br>
>> of caching, persisting and resusing state (think like PCH and modules etc).<br>
>><br>
> We have worked on projects over several years to improve these things (and<br>
> other aspects such as error-resilience). We agree there's more that can be<br>
> done, and will continue to work on this. We don't believe this approach<br>
> will get anywhere near a 100x latency improvement, which is what we're<br>
> looking for.<br>
<br>
What about pushing the state to a server?  Have a server that has the entire<br>
index, and keeps it up to date whenever a VCS commit is made to the main<br>
branch. </blockquote><div>We have this for clangd's index: <a href="https://clangd.llvm.org/guides/remote-index">https://clangd.llvm.org/guides/remote-index</a></div><div>It works great (try it out with LLVM!) but needing to deploy a server means 90% of users won't ever touch it.<br></div><div><br></div><div>(A shared repository of serialized ASTs *is* something we're considering in a tightly controlled corp environment but the barriers are pretty huge: size, security and it only works if everyone uses the same precise version of the tool. And it only makes sense at all if you're sure you can download 300MB in less than 30 seconds!)</div><div><br></div><div>David Blaikie wrote:</div><div>> Minor implementation question/request/probably already covered: Hopefully this'll be fuzz tested (both asan fuzzing for crashes, but also general behavioral correctness fuzzing too, if practical) from the start?</div><div>Thanks, we should definitely do crash fuzzing at least, will add it to the doc. I don't really understand how behavioral fuzzing would work. At google we have access to a firehose of incomplete code snapshots that we'd also use for evaluation.</div><div>(Regarding stability: C++ isn't the ideal implementation language here. But we'd like to depend on the clang lexer, be depended on by clangd, and be accessible to the C++ community).</div><div><br>> Is it expected that this will fail gracefully? (if it can't correctly perform the transformation, it'll be able to explicitly notify the user?</div><div>Two parts here: what does the parser produce and what does the tool on top of it do?</div><div><br></div><div>The parser's tree output will include places where it knows there was an error (and maybe how the error was corrected).</div><div>But in case of ambiguity it won't know, e.g. if it parsed "Foo(42);" as a function call but it was actually a constructor.</div><div><br></div><div>The behavior on top is up to the tool, e.g. an indexer needs to make a decision because it's not useful to display a warning each time you query the index.</div><div><br></div><div>> and the user has to look at the diff to understand whether the tool got it right?</div><div>Ultimately yes.</div><div>If you don't have both a human reviewer and automated tests for every change, you're on shaky ground.</div><div>This is true for human-authored changes and clang-based tools like clang-tidy too.</div><div>(Of course the accuracy level is still important!)</div></div></div>