[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