[clang-tools-extra] [clangd] [C++20] [Modules] Introduce initial support for C++20 Modules (PR #66462)

[Sam McCall via cfe-commits]

================
@@ -45,6 +45,10 @@ class GlobalCompilationDatabase {
     return std::nullopt;
   }
 
+  virtual std::vector<std::string> getAllFilesInProjectOf(PathRef File) const {
----------------
sam-mccall wrote:

The layering here looks close, but not quite right to me.

Rather than having GCDB expose "get all files" and building module-scanning on top of that, I think GCDB should expose module data: e.g. through a subobject interface like `shared_ptr<ProjectModules> GlobalCDB::getModulesDatabase(PathRef File)`, returning something like the current ModulesDependencyScanner behind an interface.

(If the interface to ModuleDependencyScanner was narrower, it could also expose those queries directly)

Reasons to prefer this:
 - suppose we augment `compile_commands.json` with some module manifest, now we want to use a different strategy for the projects that have one - which is something we only know inside DirectoryBasedCDB
 - GlobalCDB is our general "build system integration" point - if we need to swap out the high level "what are the projects and how do we talk to their build systems" strategy, we likely need to reconsider module discovery too
 - getAllFilesInProjectOf exposes more internal structure than I'd like for general GlobalCDB: we use this abstraction to integrate in cases where there's no "project" structure *and* source files are not enumerable

https://github.com/llvm/llvm-project/pull/66462