[PATCH] D137770: [docs] Introduce clangd part in StandardCPlusPlusModules

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

The status quo for modules on clangd is all flavors are completely unsupported: https://github.com/clangd/clangd/issues/1293.
I don't think we should encourage people to set up workflows that are known not to work properly and will probably break in future.

It's true that some parts work by coincidence (if you embed clang, you get all the features by default), but it's broken both in principle and in practice.

- most users don't have a version-locked clang and clangd, so relying on loading clang-produced BMI files from disk is the wrong design
- modules that get loaded somewhere inside clang never get indexed, which affects most features (e.g. code completion))
- various clangd features (include insertion, code completion ranking, unused include detection, many others) rely on the assumption that we have recorded the complete `#include` tree.
- in practice we know it's easy to get this to crash, and that users who follow instructions and get crashes expect support

To get to a better state someone needs to design and build support for modules in clangd. This is a major project. (Based on the discussions we've had so far, I *don't* expect the solution to look like "adopt clang's support" but rather require significant new infrastructure).

It's also one that doesn't currently have an owner. Unfortuntately (which has funded much of clangd's development) it's not likely to be a priority for $EMPLOYER unless/until we're using C++20 modules ourselves. (And we have less time to work on clangd at all, these days). We're open to someone else driving it (I know some folks from Meta were looking at this) as long as we head towards a design that's likely to be widely useful (e.g. no version lock, plan to work with common build systems).

This situation is not at all obvious to users, and I'm impressed you managed to figure out the bits that work! I think we should clarify the situation by making clangd emit an error when modules are enabled (we can disable this with a flag like `--experimental-modules` for people that want to work on modules support/test it once someone works on it).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137770