[clangd-dev] New LSP language service supporting Swift and C-family languages, using clangd

[Ilya Biryukov via clangd-dev]

Hi Argyrios,

Thanks for sharing details on the new language server.

We will obviously keep improving the standalone clangd, including the
indexing and refactoring experience. I'm personally confident we can
accommodate your use case as well, it takes a little work to make sure we
keep the single-file no-index case working in clangd, but that shouldn't be
too much work.

Is it fair to say the design is driven by the fact that the LSP protocol
itself has no way of doing cross-language interactions without baking all
of the involved languages into the same language server?
Another non-language-specific reason that I see is the lack of
index-while-build support  on our side (and lack of control over the build
and the compiler in general).



Am Di., 23. Okt. 2018, 08:32 hat Argyrios Kyrtzidis via clangd-dev <
clangd-dev at lists.llvm.org> geschrieben:

> Hey all,
>
> 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 (
> https://forums.swift.org/t/new-lsp-language-service-supporting-swift-and-c-family-languages-for-any-editor-and-platform).
> I wanted to also mention additional details that relate to Clangd.
>
> 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 (https://symas.com/lmdb). The
> functionality of this library is described by Nathan in his
> Index-While-Building design document (
> https://docs.google.com/document/d/1cH2sTpgSnJZCkZtJl1aY-rzy4uGPcrI-6RrUpdATO2Q),
> specifically in the 'Using the index store' section.
>
> 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).
>
> 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.
>
> 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,
> https://lists.llvm.org/pipermail/cfe-dev/2018-April/057668.html and what
> kind of improvements we want to make.
>
> 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!
> _______________________________________________
> clangd-dev mailing list
> clangd-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/clangd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/clangd-dev/attachments/20181023/8614b5d8/attachment-0001.html>