[SizzleUnrlsd]

Part 1 of #184: the working-directory race, and four defects found while reviewing the fix. Part 2 (the cost of the ownership summaries) is #187, which carries these commits and is the PR planned for delivery.

Problem

A compile that needs its compile command's directory changes the working directory of the whole process (ScopedCurrentPath). With automatic jobs, the default, save/restore pairs interleaved: a file could compile from another file's directory, and the process could stay in one of them. Relative paths opened later, the resource model and the caches among them, then failed. In the CI self-analysis, the resource model is passed relatively. Locally, on main f065508, every finished run of a chunk printed "cannot open model file" 14 to 27 times. The effect on the CI runs themselves is not established.

The reviews of the fix found four more defects:

• Wrong header. A command with a directory was first compiled from the current directory, and from its own only when that failed. When both directories hold a header of the same name, the start directory's one is used, with no error. This happens on main with --jobs>1, and with automatic jobs after the first fix.
• Missing model. A requested model that cannot be read is logged on stderr, and the run ends with code 0 and no finding. run_code_analysis.py then reports "CI gate passed".
• Relative inputs with parallel compiles. Once every command compiles from its own directory, another thread could resolve its relative input path against that directory. With 24 files given by relative paths, --jobs=4 failed with "No compile command found for: src/unit03.c", where main succeeded.
• Stale compile IR cache. The IR built from the wrong directory stayed in the compile IR cache, under the same key and schema, and was reused after the fix.

Changes

• The compile lock covers the whole directory change. The compile lock is taken before the directory change and held until it is undone; the separate fallback lock goes.
• Relative paths are anchored to the start directory. The resource, escape and buffer models, the compile IR and resource summary caches, --dump-ir and the compile database are anchored there once the arguments are parsed.
• Every compile command runs in its own directory, whatever the job count. The "optimistic fast path" that compiled from the current directory first goes. It predates the lock that serializes every compile (967be74), so it no longer ran anything in parallel.
• Relative inputs resolve from the start directory. That directory is recorded once, as AnalysisConfig::inputBaseDir, with the other anchored paths, before any input loads. Every access to an input goes through its path resolved from there: compile command lookup, compile, cache keys, reading. The path given is kept for messages and results (fix(report): spell every result's file as the input was given #124).
• The compile IR cache moves to schema v3, in its key and in the metadata of each entry, so the entries built by the previous pipeline are compiled again.
• An unreadable model stops the run. Before any input is loaded, a resource, escape or buffer model given on the command line or in the config file must be a readable file. Otherwise the run stops with Cannot read <kind> model file: <path> and exit code 1, and the CI script fails.

This check covers missing and unreadable files only. A model that can be read but holds malformed rules is still reported on stderr and skipped by the analysis. That is a separate question, noted in the README. A compile from its command's directory still changes the directory of the whole process while it runs. Removing that requires compilerlib to compile against a working directory of its own: clang's -working-directory would not avoid it, as compilerlib gives the driver the real file system, whose working directory is the process's.

Tests

• check_resource_model_across_compile_directories. It uses 8 files, each in its own compile directory, with the header it includes through a relative -I. A model given relatively alone defines each file's leak, and the start directory holds, for every file, a header of the same name that drops the leak. With automatic jobs, --jobs=1 and --jobs=4, with the files given by absolute and then by relative paths, three runs each with empty caches of their own, the check requires the 8 leaks and nothing else, each file named as it was given. It also requires caches under the start directory and anchored paths in --print-effective-config.
  • On main, automatic jobs fail every run, and --jobs=4 reports no leak.
  • On the first fix (3b2260e), automatic jobs and --jobs=4 report no leak.
  • On e2e9f87, 5 of the 6 parallel runs with relative paths fail.
• check_compile_ir_cache_rebuilds_previous_schema. The start directory and the compile command's directory hold a header of the same name, giving 7 and 42. After a run with an empty cache (42), the check rewrites the entry as the previous pipeline left it: the previous schema and 7, with sources and dependencies valid. The next run must compile again, give 42 and rewrite the entry, and the run after it must reuse that entry. It covers the schema in the metadata; an entry under a previous key is never looked up. On c5911fb the stale entry is reused (7).
• check_unreadable_model_fails. A missing file and a directory, for each of the three model options, must give a nonzero code that names the path. run_code_analysis.py with a missing model must fail. On 274c1c1, all six runs exit with 0 and the script passes.

Locally (macOS arm64, on main c1e60b8, head 7962221), run_test.py passes 2383/2383, both without and with CI's compile IR cache option, and both unit-test binaries pass.

CI

The Self-analysis step on this PR's head (7962221) took 11 min 21 s against its 15-minute limit (8 min 31 s on e2e9f87). The ownership summaries are still the previous ones; #187 brings this down. Since #190 moved the resource summary cache to schema v5, the cache CI restores holds no entry this run can read, so the run is cold.

Code scanning

• This PR introduces no open alert.
• Alerts 254 and 255, shown after the first push, are now fixed: AnalyzerApp.cpp is no longer changed by the first fix.
• The other alerts listed on this PR already exist on main.

Refs #184