[SizzleUnrlsd]

Summary

Every compilation held gCompileInvokeMutex and moved the whole process to its compile command's directory, so the --jobs threads compiled one source at a time (#271). coretrace-compiler now gives each compilation the directory of its -working-directory without moving the process (CoreTrace/coretrace-compiler#262): the analyzer passes each compile command's directory that way, and compilations share the lock.

Closes #271

Change

• build(deps): pin coretrace-compiler to its per-compilation working directory: a commit of feat(compilerlib): give each compilation a working directory of its own coretrace-compiler#262, a draft. This pull request waits for it, and should pin the release that brings it.
• perf(input): compile sources in parallel, each in its directory:
  • -working-directory <directory> is prepended to the compile command's arguments; ScopedCurrentPath, which moved the process, is gone;
  • compilations take the lock shared. Those with an option that Clang applies to LLVM's state for the whole process (-mllvm, -mdebug-pass, -mlimit-float-precision, -ftime-report), or with -fno-integrated-cc1, whose jobs run as programs for which coretrace-compiler moves the process, take it alone, as coretrace-compiler asks.
• docs(readme) and docs(changelog).
• build(deps): pin coretrace-compiler to its fix of the files -MJ writes: a newer commit of feat(compilerlib): give each compilation a working directory of its own coretrace-compiler#262, which also writes the fragment of -MJ, the statistics of -save-stats, the graph of -dependency-dot and the module cache in the directory of -working-directory, where this analyzer wrote them when it moved the process there.

A compile command whose directory does not exist still fails the analysis, with the message it gave before. coretrace-compiler reports such a directory, but compiles to memory all the same (CoreTrace/coretrace-compiler#264), so the analyzer checks the directory itself before compiling.

Measurements

macOS arm64 (M3, 8 cores), LLVM 20.1.2, --format=json --timing, no IR cache, an empty resource summary cache. Both builds use coretrace-compiler from source: main (f0a22d9) for db7fb25, CoreTrace/coretrace-compiler#262 for this branch. Medians of 5 runs, 3 for the 53 sources; the builds alternate within each repetition.

Sources	--jobs	db7fb25	this branch	Loading: db7fb25, this branch
Lua 5.4.6, 34 C files	1	7.70 s	7.71 s	1.14 s, 1.17 s
	2	7.68 s	7.51 s	1.12 s, 0.90 s
8 C++ files, each including 11 standard headers	1	4.27 s	4.07 s	3.81 s, 3.68 s
	2	4.39 s	2.61 s	4.03 s, 2.22 s
This repository's 53 C++ sources	1	55.0 s	55.1 s	44.1 s, 43.9 s
	2	52.3 s	34.1 s	42.2 s, 23.7 s

• Reports: the same diagnostics and functions with both builds, at both job counts. The order of Lua's diagnostics, and so their ids, varies from run to run with either build.
• Peak memory grows with two compilations in flight: at --jobs=2, 239 MB to 328 MB for the 8 C++ files, 1.26 GB to 1.42 GB for the 53 sources.
• The analysis is not changed: on Lua it takes 6.5 s of the 7.7 s (Multi-file runs analyze their modules one at a time, whatever --jobs #199).
• More jobs were not measured, to keep the machine usable.

Tests

Local runs, on macOS arm64 with AppleClang and LLVM 20.1.2, this branch built as a user builds it, coretrace-compiler fetched at the pinned commit, so that the compile IR cache is in use:

• run_test.py --jobs 2 --no-cache: 2696/2696 at the head, e6ae53e, at d642039, before the second pin, and at the first commit, the first pin alone. check_resource_model_across_compile_directories compiles eight sources, each from a directory of its own with a header of the same name as a decoy in the start directory, at the default, 1 and 4 jobs.
• A compile command whose directory does not exist: the analysis fails with Failed to change working directory to: <directory>, as with db7fb25.
• scripts/format-check.sh with clang-format 20, scripts/check-license-compliance.sh and the commit checker pass.