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

[Chuanqi Xu via cfe-commits]

================
@@ -0,0 +1,81 @@
+//===---------------- ModuleDependencyScanner.cpp ----------------*- C++-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include "ModuleDependencyScanner.h"
+#include "support/Logger.h"
+
+namespace clang {
+namespace clangd {
+
+std::optional<ModuleDependencyScanner::ModuleDependencyInfo>
+ModuleDependencyScanner::scan(PathRef FilePath) {
+  std::optional<tooling::CompileCommand> Cmd = CDB.getCompileCommand(FilePath);
+
+  if (!Cmd)
+    return std::nullopt;
+
+  using namespace clang::tooling::dependencies;
+
+  llvm::SmallString<128> FilePathDir(FilePath);
+  llvm::sys::path::remove_filename(FilePathDir);
+  DependencyScanningTool ScanningTool(Service, TFS.view(FilePathDir));
+
+  llvm::Expected<P1689Rule> ScanningResult =
+      ScanningTool.getP1689ModuleDependencyFile(*Cmd, Cmd->Directory);
+
+  if (auto E = ScanningResult.takeError()) {
+    log("Scanning modules dependencies for {0} failed: {1}", FilePath,
+        llvm::toString(std::move(E)));
+    return std::nullopt;
+  }
+
+  ModuleDependencyInfo Result;
+
+  if (ScanningResult->Provides) {
+    ModuleNameToSource[ScanningResult->Provides->ModuleName] = FilePath;
----------------
ChuanqiXu9 wrote:

> i think it might be better to change the layering a little bit, so that we can scan for a single file (possibly with contents coming from a virtual buffer, as clangd can operate on non-saved files) without triggering the scan on the whole project (e.g. ModulesBuilder::buildPrerequisiteModulesFor should probably retrieve RequiredModules for current file without consulting the full module-graph). But I can see that's a big change, it's fine to do that in a follow up patch.

Maybe due to I am the author, I feel the code here is almost natural and not complex. And I agree that there will be a lot of spaces to improve in the future.

> sorry i was rather talking about projects that enabled modules, but contain files that do not use modules, as in such a project we shouldn't really expect any files that don't use modules (at least that's my understanding, happy to be proven wrong).

It should be true for some small grained project like I listed above. But let's image a big project just like LLVM which has a lot of sub-module. We can image if someday modules goes to LLVM, it won't be the case that all of the headers gone in one night. It must be a pretty long process to refactor the code base step by step and remain the headers for a relative long time to backup or for backward compatiblity. And this is exactly what we have internally.


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