This fixes the underlying module dependencies, which had a non-deterministic order, which was also visible in the order of calls to DependencyConsumer methods. This was not directly observable in the clang-scan-deps utility, because it was previously seeing a sorted order from std::map in DependencyScanningTool. However, the underlying API previously created a likely issue for any other clients. Note: if you only apply the change from DependencyScanningTool, you can see the issue in clang-scan-deps, and existing tests will fail non-deterministicaly.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp | ||
---|---|---|
179 | What's the reason for wrapping ModuleDeps in unique_ptr? |
clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp | ||
---|---|---|
179 | Oh hmm, my thinking was that DenseMap is optimized for small values, but I guess in this setup the map only stores integers and the values are in a vector. I'll change this to values, thanks! |
Removed use of std::unique_ptr in DependencyScanningTool.cpp, per review feedback.
@jansvoboda11 Note: there is another map containing std::unique_ptr<ModuleDeps> in ModuleDepCollector, but that one is required for correctness. The problem is that there is code that forms a ModuleDeps & lvalue and assumes it will be correct after mutating the containing ModularDeps map. For example, the signature of addAllSubmoduleDeps requires this. If we want to switch to using this as a value in the map, we would need to do the lookup in the map again after each mutation. This code worked previously with unordered_map, because it guarantees that keys and values are not mutated by unrelated mutations of the containing map, unlike MapVector. In practice, this means there is no additional overhead from the unique_ptr, because it was already doing a separate allocation for each value in the unordered_map.
What's the reason for wrapping ModuleDeps in unique_ptr?