[PATCH] D140176: [clang][deps] NFC: Split out the module-based API from the TU-based API

Artem Chikin via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Dec 16 11:37:53 PST 2022


artemcm requested changes to this revision.
artemcm added inline comments.
This revision now requires changes to proceed.


================
Comment at: clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h:111
+  /// information needed for explicit build.
+  llvm::Expected<ModuleDepsGraph>
+  getModuleDependencies(StringRef ModuleName,
----------------
The existing [[ https://github.com/apple/swift/blob/main/lib/ClangImporter/ClangModuleDependencyScanner.cpp#L247 | client ]] of the `ModuleName` API queries a single module and it's nice to get a structured output of a `FullDependenciesResult` for the module being queried itself, and get its dependencies from that. Whereas now we will just be getting a sequence of `ModuleDeps`s. So just to confirm, if a client queries `getModuleDependencies("Foo", ...)`, the resulting `ModuleDepsGraph` will contain a `ModuleDeps` for `Foo` itself also, and not just `Foo`'s dependencies? 

Still, the client will now need to traverse this graph to find `Foo` in particular, and it'd be nice to not have to do that. `TranslationUnitDeps` is not the right thing here, but perhaps something simpler could work, along the lines of:
```
struct SingleModuleDeps {
  ModuleDeps mainQueriedModule

  /// The graph of direct and transitive modular dependencies of mainQueriedModule
  ModuleDepsGraph ModuleGraph;
};
```
What do you think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140176



More information about the cfe-commits mailing list