[cfe-dev] Adding indexing support to Clangd

Marc-André Laperle via cfe-dev cfe-dev at lists.llvm.org
Fri Sep 8 13:39:31 PDT 2017



On 2017-08-10 05:56 AM, Ilya Biryukov wrote:
> One thing that is really important for us at Google is to come up with 
> the index interface (for both querying and building an index) that 
> would allow an alternative implementation that could scale for larger 
> codebases.
> That should not require significant changes to your design, merely 
> extracting a few interface classes and figuring out the APIs should be 
> easy.
> We could figure it all out during the review process and I would 
> highly encourage to start a review as early as possible.
>

It's good to know that you are interested in replacing the 
implementation. The higher level classes are not very polished right now 
so as I improve things, I will keep that in mind. For example, right 
now, the data storage component is not fully hidden from the indexing 
interface.

BTW, I started putting the indexing prototype on Github [1]. The lower 
level "storage" parts (ClangdIndexDataStorage, BTree) I think could be 
ready for review soon but with the discussions about Sqlite and LMDB, 
I'm not sure if that's the way to go yet. I'll have to research more 
LMDB especially and also in the light of the index-while-building proposal.
The file event handling, indexing operations and model are all prototype 
level so not ready for review yet (lots of TODOs and *long* methods) but 
they help to know how the pieces can fit together. The 
index-while-building proposal contains some good ideas on how to model 
things too and I think it makes sense to align on that. There are also 
some protocol parts in the prototype that could also be reviewed soon, 
if it's OK for some handlers to not do anything for a while.
I'll determine what the next steps should be and keep you posted.

[1] 
https://github.com/MarkZ3/clang-tools-extra/commits/IndexFunctionsPrototype

Regards,
Marc-André

> We could add the index modification APIs during the review process as 
> well.
> The lack of header caching in the first implementation is fine. That's 
> something we should iterate on later. That's a hard problem and it 
> seems fine if we solve it separately.
>
> Wish you a great vacation!
>
> --
> Regards,
> Ilya Biryukov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170908/a53619fb/attachment.html>


More information about the cfe-dev mailing list