For users of the C++ API, the return type of getFullDependencies doesn't make sense when asking for dependencies of a module. In the returned FullDependenciesResult instance, only DiscoveredModules is useful (the graph of modular dependecies). The FullDeps member is trying to describe a translation unit it was never given. Its command line also refers to a file in the in-memory VFS we create in the scanner, leaking the implementation detail.
This patch splits the API and improves layering and naming of the return types.
Depends on D140175.
The existing 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 ModuleDepss. 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:
What do you think?