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

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu planned changes to this revision.
ChuanqiXu added a comment.

@sammccall Thanks for you professional and valuable input. It is very helpful. From the perspective of clangd, it looks not good indeed that the user can't get a stable support for modules.

> 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).

Could I interpret your words as the following?

- We should and could emit an error in clangd if it detects we're using modules.
- We can add a flag `--experimental-modules` to skip such errors.

If yes, I think I know how to implement this. We can add a PPCallbacks, which implement the `moduleImport` callbacks so that we can know it is importing a module (or declare a module). This should be the proper way. And we can use (and document) the `experimental-modules` flag to get the facility today (and better in future). Or in another word, the tests in D137693 <https://reviews.llvm.org/D137693> can't be passed. But if could be if we add the `experimental-modules` flag  to the clangd. Do I understand correctly?

---

The following off is the plan in the longer term. From my point of view, your word mentions 2 different concern:

- inner concern: we need new design in the clangd to make clangd understand modules really.
- outer concern: we need an protocal between clangd and the build system to allow the clangd to inform the build system to build modules. And we need the compiler (clang) to parse the module file from different versions.

>From my point of view, both concerns are hard to address. While I don't know a lot about the implementation details about clangd, both of the two outer concern are not easy to address. (Although they are absolutely the correct direction, of course). I'm afraid that I can take it. But I'll try to look at the implementation of clangd more (I've tried to read it for a few days and it is not easy indeed) to have a strong feelings.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137770