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

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

Hi Kugan, I apologize in advance for a frustrating and long-winded answer...

There's no modules support in clangd in large part because we don't know where to start.

- clangd devs so far are not experts in modules and didn't have a burning use case, I suspect you can help a lot or both counts!
- we expect using modules to have very high implementation and maintenance costs, so it's a big bet:
  - they are similar to preambles, and preambles greatly constrain and complicate most clangd features
  - ... but they have many more permutations than preambles, so are harder to reason about and test, we will have more types of bugs...
  - these are being added on, unlike preambles which were added early and much of our infrastructure was designed around (TUScheduler, index)
- there's no established pattern for tools working with modularized build systems yet (c.f. compile_commands.json 5 years ago)

There's huge potential benefits here and I'm excited you're working on it! But because of the high costs, we need to make sure this is going to improve things substantially for many users. The more that a design assumes version-lock, PCMs are guaranteed present, host compiler flags are clang-compatible (clang/gcc/msvc all use diferent modules flags!), even explicitly modularized code, the narrower the slice of users there are.

It's tempting to start down the path of trying to fix the configuration that almost-works. We can/should definitely support experimentation! (The COMPATIBLE_LANGOPT change here seems fine to me). But even if the first steps are cheap, going down too far down the wrong path can be expensive. My biggest fear is to end up supporting increasingly costly fixes to an accidentally-supported mode that will never really work right. 
But I should worry less and talk more - looking forward to a video call on thursday, I'm sure we'll find a good way forward!

I think first steps are pretty high level, to understand:

- what the goals are (e.g. performance, easier integration with build system, work with modules syntax features, ...)
- environment and constraints (e.g. how your build system works, how clangd interacts with headers today)
- alternatives for achieving goals (externally built modules, internally built modules, some hybrid where modules are optionally provided, non-modules solutions...)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124909