[PATCH] D124909: Fix issues with using clangd with C++ modules

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

To back up a bit...

Until now I don't think we've had a serious effort/plan for supporting modules in clangd, or AFAIK in clang tools in general.
To the extent that modules work, it's a side-effect of how we use clang's driver + compilation database, and inherit behavior by default.
So we probably need a bit of discussion of what configurations should be supported, how they should be configured & interact with the build system etc.

If I understand right (not a modules expert) in a build system:

1. modules can be produced by the build system as a separate step, and passed to build actions (e.g. -fprebuilt-module-path or -fmodule-file)
2. or they can be built on demand by compile steps that use them in a clang-private cache dir (-fimplicit-modules)
3. or we can have a build with no modules at all

If I understand right, you want to support a build system that does 1.
This makes sense (I suspect we should support 2 as well one day, but we can call it out of scope for now)

In clangd we'll see the compile commands used by the build system, via e.g. compile_commands.json, and again we have several strategies:

- we can consume modules from the build system
- we can build the needed modules in some clangd-private storage
- we can disable modular compilation, and parse headers textually

I think this patch intends to support strategy 1 (for build systems that produce modules).

My concern here is that this is fragile:

- the PCM format is not stable, clangd can only consume module files if the build system is using clang and that clang is built from the exact same revision. This is hard to achieve for most users. (And compile_commands.json having module-related flags in it a signal that it is true)
- clangd may now/later parse headers in different modes, skip function bodies etc. The COMPATIBLE_LANGOPT changes hint at the problems we can run into trying to reuse modules - it seems likely we'll run into issues later (compatibility, but maybe also performance?)
- if the modules are produced by the build system, clangd doesn't get a chance to examine the source code or AST directly. How does the dynamic index work on modular code? How do we know its include structure?

There may well be good reasons to handle modules this way, but let's work out the implications before this ends up in production! :-)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124909/new/

https://reviews.llvm.org/D124909