This patch makes sure the ordering of TUs in the input CDB is preserved in the full output. Previously, the results were pushed into a global vector, potentially out-of-order and then sorted by the input file name. This is
non-deterministic when the CDB contains multiple entries with the same input file. This patch fixes that by pre-allocating the output vector and instead of appending, writes to the index corresponding to the current input. This also
eliminates one critical section.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/tools/clang-scan-deps/ClangScanDeps.cpp | ||
---|---|---|
291–293 | Since the input index is coming from "outside": does this operator[] assert if the index is out of range? If not, we should do so here. I would also suggest asserting the value isn't already populated (e.g. assert(ID.FileName.empty())). | |
790 | Since you should never resize FullDeps after you start, how about removing resize and instead:
|
clang/tools/clang-scan-deps/ClangScanDeps.cpp | ||
---|---|---|
790 | We don't want to resize when we're only scanning by module name, in that case our input is not a translation unit. I implemented your idea and will try to improve how we model the result types in a follow-up. |
Hi, this new test fails on AIX, could you take a look please?
https://lab.llvm.org/buildbot/#/builders/214/builds/6148/steps/6/logs/FAIL__Clang__modules-full-output-tu-order_c
-fno-integrated-as strikes again. Thanks for reporting this, should be fixed in 3ac8d32.
Thanks for addressing this. Unfortunately the test is still failing after the fix and a clean build
Since the input index is coming from "outside": does this operator[] assert if the index is out of range? If not, we should do so here. I would also suggest asserting the value isn't already populated (e.g. assert(ID.FileName.empty())).