================ @@ -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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
