<div dir="ltr"><div dir="ltr">On Mon, Nov 8, 2021 at 11:18 AM Haojian Wu <<a href="mailto:hokein@google.com">hokein@google.com</a>> wrote:<br></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"><div dir="ltr"><div dir="ltr">IDE use cases (for clangd)<br></div><div class="gmail_quote"><div>-  provide code-folding, outline, syntax highlighting, selection features without a long "warmup" time;</div><div>-  a fast index to provides approximate results;</div><div><br></div><div>Other use cases we aim to support:</div><div>- smart diff and merge tool for C++ code;</div><div>- a fast linter, a cpplint replacement, with clang-tidy-like extensibility;</div><div>- syntactic grep/sed tools;</div></div></div></blockquote><div><br></div><div>* I don't know what "fast index to provide approximate results" means.  Results of what?  Do you mean generating an index?  What will the index be used for?</div><div><br></div><div>* 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.</div><div><br></div><div>* 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).</div><div><br></div></div></div>