[clangd-dev] Clangd Path Mappings for Docker Container

[Sam McCall via clangd-dev]

Hi William,

This is an idea Ilya did some thinking about before. The motivation was
slightly different (editor on laptop, clangd on remote workstation) but I
believe equivalent.
We're not going to get around needing to have all sources on both machines
(or mounted from one to the other). Clangd and the editor both need to see
them. So I think the path translation is indeed the bit to attack. The
scary thing about adding file mapping is doing it consistently everywhere
without making mistakes or adding lots of noise to the code.

An idea I want to throw out there: clangd performs reads via a VFS. This is
an existing abstraction where path translation could be added without any
additional complexity to clangd proper.
The way this would work: we give clangd a different view of the world and
connect it directly to the editor (on the host). This means clangd needs to
speak the host's language, so the VFS needs to simulate the FS layout of
the host.
This leads to the main limitation: we need a compilation database that's
consistent with the *host's* file layout. I suspect mechanically
transforming compilation databases is hard (relative paths etc), so this
may mean running the build system on the host (at least sufficiently to
generate the CDB).
Not sure if there's a way to modify this idea to avoid the limitation.

I'm interested in how else we can get clangd to expose a different view of
the world than its VFS sees in a consistent way, too!

On Thu, Jan 10, 2019 at 9:12 AM William Wagner via clangd-dev <
clangd-dev at lists.llvm.org> wrote:

> Hello,
>
> I’ve been using clangd for developing a C++ project at work. Our
> development setup requires that we build and run our code inside a docker
> container. From a language server perspective this presents a few
> challenges:
>
>
>    1. Communicating with the language server running in the container
>    2. Synchronizing the files between the host and the container
>    3. Translating file paths between the host lsp client  and docker lsp
>    server
>    4. Having dependency files that are only in the container available to
>    view on the host (for textDocument/definition on dependencies installed
>    only in the container)
>
>
> Fortunately, docker’s facilities make 1) and 2) pretty easy to deal with.
>
> 1) can be solved by creating a bash script that contains something similar
> to:
> `docker exec -i <build_container> /path/to/clangd ${@:1}`
> and pointing clangd.path to this script
>
> 2) can be solved by using a docker bind mount, which maps the directory of
> the project you’re working on into the container
>
> 3) can be solved by mounting the host:/path/to/project to an identical
> path in the container. Then there doesn't have to be any translation
> between the requests/responses between the file uris that the client and
> server send back and forth. However, this may not always be possible and
> still leaves the problem of external dependency paths.
>
> 4) has no easy solution yet afaik. A potentially simple one would be to
> copy just the dependency headers from the container over to some directory
> on the host, and be able to translate clangd response file uris to the
> appropriate path on the host. The way I envision that is an extra arg to
> the clangd server that supports path substitution, such as:
>
> `clangd
> -path-mappings=’/host/home/project/deps:/container/deps;/host/home/project/:container/project`
>
> So if I “Go To Definition” on an external symbol e.g. Foo, which is
> defined in /container/deps/foo.hh”, and I have the foo.hh header in
> /host/home/project/.deps/foo.hh, then the response from the servers
> textDocument/definition would substitute the /container/deps/foo.hh →
> /host/home/project/.deps/foo.hh and all would be well.
>
> I believe sourcegraph has implemented an extension to the LSP to handle
> missing files on the client/server, but I cannot find the proposed spec.
> Also these are some github discussions that touch on the topics above:
>
>    - Ccls supports a path Mappings config option that allows
>    substitution, see https://github.com/MaskRay/ccls/issues/75
>    - Discussion on remote langauge server proposal
>    https://github.com/Microsoft/language-server-protocol/issues/528
>
>
> I’d be happy to implement this path mapping functionality, but thought
> it’d be prudent to see what everyone else thinks before doing so.
>
> Thanks!
>
>
> _______________________________________________
> 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/20190110/94d8a04d/attachment.html>