================ @@ -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:
> Are we really going into all this complexity to optimize the case of files > with no modular dependencies? Yes, this is primarily the reason why we delay it. > files with no modular dependencies is going to be so rare in practice This assumption is not true to me unless we're talking about the ecosystem 10+ years later. (There is a website (https://arewemodulesyet.org/) tracking the progress. Although its progress bar is almost a joke). Since programmers needs to refactor their code to use C++20 modules, we believe there will still be a lot of files unrelated to modules exists. Especially for headers. To make this more clear, currently, there are 2 ways to use modules. One is to use modules extensively and get rid of headers. Examples are https://github.com/infiniflow/infinity and https://github.com/davidstone/technical-machine, where we can see rare headers and almost all the files are related to modules. However, there are more projects are simply wrapped themselves with modules, so that the users can consume the library by including or by importing by their interest. (Or even importing in some .cc and including in some other .cc if the size of the code bases it too big). Most projects on the previous mentioned website uses this model. From the perspective, I think the assumption that modules-native (I called it) style won't take the place all over the world soon. > so having this extra mental load and requirements about an implementation > detail that doesn't bring much benefits in practice, and planned to be > stripped away is just too much for maintenance. Of course, since the first patch is not focus on performance and the design, I can drop it if you really don't like it. 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
