<div dir="ltr"><div dir="ltr">Hi Argyrios,<div><br></div><div>Thanks for the update! I think the design makes sense, and having a cross-language index will allow really nice mixed-language project support.</div><div><br></div><div>There is a lot of implementation overlap, the design we ended up with is actually pretty similar: auto-index (<a href="http://tinyurl.com/clangd-automatic-index">http://tinyurl.com/clangd-automatic-index</a>) extracts the symbols/refs from TUs, and then we build a queryable index structure on top of it (Dex). It's all in-process, but conceptually not too different than the background-clang-worker variant.</div><div>We started with a dynamic index which just has opened TUs, and a static one built by a mapreduce-like process, and autoindex is these approaches meeting in the meddle. We'd actually hoped to rely on index-while-build infrastructure for some of this, but it didn't arrive in time.</div><div><br></div><div>That said, the devil is in the details: actually sharing an implementation of the index layer would probably be hard, as we're all getting pulled in different directions.</div><div>If it's possible to plug your index into the SymbolIndex abstraction in clangd, then lots of features will "just work", like fast code completion. Clangd relies on the index for that today rather than the caching approaches used by libclang.</div><div>We've had multiple implementations of this (including a large-scale out-of-process one internal to Google), but so far they've all mostly shared indexing logic. So I'm curious whether this is actually implementable on different data sources like what you'll get from index-while-build.</div><div><br></div><div>One question I have is a practical one - I'm sure changes are needed to clangd, are these likely to happen upstream or in a fork/merge cycle?</div><div><br></div><div>Looking forward to seeing more details!</div><div>Cheers, Sam</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 23, 2018 at 8:32 AM Argyrios Kyrtzidis via clangd-dev <<a href="mailto:clangd-dev@lists.llvm.org">clangd-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Hey all,<br><br>We've recently announced that we'll be starting a new open-source project for an LSP language service supporting Swift and C-family languages, see more details in the announcement post (<a href="https://forums.swift.org/t/new-lsp-language-service-supporting-swift-and-c-family-languages-for-any-editor-and-platform" target="_blank">https://forums.swift.org/t/new-lsp-language-service-supporting-swift-and-c-family-languages-for-any-editor-and-platform</a>). I wanted to also mention additional details that relate to Clangd.<br><br>Currently, for our C-family support in Xcode (code-completion, clang AST queries) we use libclang, but for the new LSP service we will switch to using Clangd. We will also open-source a C++ library for global index queries, which is built on top of LMDB (<a href="https://symas.com/lmdb" target="_blank">https://symas.com/lmdb</a>). The functionality of this library is described by Nathan in his Index-While-Building design document (<a href="https://docs.google.com/document/d/1cH2sTpgSnJZCkZtJl1aY-rzy4uGPcrI-6RrUpdATO2Q" target="_blank">https://docs.google.com/document/d/1cH2sTpgSnJZCkZtJl1aY-rzy4uGPcrI-6RrUpdATO2Q</a>), specifically in the 'Using the index store' section.<br><br>Let me elaborate a bit more on how we use this library. From Clang (and Swift) we get raw index data files, either directly from building or from invoking clang for background indexing. These data record files are designed to be efficient to write and update, ensuring that record files for headers are only written once, so that index-while-building has minimal overhead. But they are not designed to do efficient global queries (give me all symbol occurrences of this symbol USR). To accommodate this we use this database library which is a lightweight index layer on top of the raw index records. It reads the raw index data files and populates a key-value database that enables efficient global queries (it essentially determines what raw index record files contain the relevant information and retrieves the data).<br><br>In our design for having full cross-language support for Swift and Clang languages (e.g. call-hierarchy across languages), we prefer to have a language-independent indexing component that is layered on top of the compiler-specific support (Clang/Clangd and Swift/sourcekitd). That means that our LSP service will contain an indexing and global refactoring engine and it will delegate to Clangd for clang-specific document queries, like code-completion.<br><br>I understand that Clangd is intended to be a self-contained language service, that includes functionality for global index queries along with document-specific queries, but we believe we could still collaborate on common infrastructure shared by both Clangd and our new cross-language LSP service. See AlexL's previous post about how we intend to use Clangd, <a href="https://lists.llvm.org/pipermail/cfe-dev/2018-April/057668.html" target="_blank">https://lists.llvm.org/pipermail/cfe-dev/2018-April/057668.html</a> and what kind of improvements we want to make.<br><br>Once we have the repositories up, you'll be able to check out our overall design in more detail, and in the meantime I'd be happy to hear any feedback or questions you may have!</div>_______________________________________________<br>
clangd-dev mailing list<br>
<a href="mailto:clangd-dev@lists.llvm.org" target="_blank">clangd-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev</a><br>
</blockquote></div>