harness-scratch is red on master: corpus_zig_bodies.rs keys its scratch dir by pid

[gHashTag]

tri harness scratch --gate has been red on master since 994f3c8a3:

test binaries whose tests share one scratch directory
    bootstrap/tests/corpus_zig_bodies.rs     3 tests   key t27-corpuscols-{}

bootstrap/tests/corpus_zig_bodies.rs:86 is

let dir = std::env::temp_dir().join(format!("t27-corpuscols-{}", std::process::id()));

A pid is one value per process, so every test in the binary resolves the same
directory, and the test that uses it ends with remove_dir_all(&dir).

What is measured, and what is not. Only one of the three tests in that file
creates or deletes the directory today, so there is no collision on this tree --
the gate is structural, and correctly so: the second test to use that key would
collide, and it would pass the first time it ran.

The fix is the one the gate's own message prescribes: key by an AtomicUsize
counter, unique per call, rather than by the pid.

Master runs: 994f3c8a3 failure, 494265fbb success, d7fdb4f1d success.

[gHashTag]

Recovered: another session's work-in-progress, swept in and returned

While building this fix, git add -A swept 44 lines of bootstrap/src/compiler.rs
and its FROZEN_HASH into my branch. They are not mine — a C and Rust emitter
fix for string literals (extra_kind == "string", referencing W560).

How it reached a clean worktree: the stash stack is shared across every
worktree of a repository. An earlier command of mine ran git stash -q -u on a
tree with nothing to stash — which pushes nothing — and then git stash pop -q,
which popped the top of the shared stack: somebody else's work in progress. The
pop succeeded, so that stash entry is gone from the stack.

Reverted from the branch in 336c328b7. The work is preserved in two places:
commit 1c00afecb on fix/scratch-dir-pid, and verbatim below.

the patch, verbatim

diff --git a/bootstrap/src/compiler.rs b/bootstrap/src/compiler.rs
index 51176297e..51d1a3884 100644
--- a/bootstrap/src/compiler.rs
+++ b/bootstrap/src/compiler.rs
@@ -18360,11 +18360,18 @@ impl CCodegen {
             let child = &node.children[0];
             // Simple literal → #define
             if child.kind == NodeKind::ExprLiteral {
-                self.write_line(&format!(
-                        "#define {} {}",
-                        node.name,
-                        Self::c_literal(&child.value)
-                    ));
+                // `c_literal` takes a &str and so cannot see the lexer's
+                // `extra_kind == "string"` tag, which lives on the NODE. A
+                // string constant therefore emitted `#define NAME trinity` --
+                // and that is worse than a compile error, because a #define of
+                // a bare word is valid C. It lands in the output and fails
+                // wherever it is used, or expands to something else entirely.
+                let text = if child.extra_kind == "string" {
+                    format!("\"{}\"", Codegen::zig_escape(&child.value))
+                } else {
+                    Self::c_literal(&child.value)
+                };
+                self.write_line(&format!("#define {} {}", node.name, text));
             } else {
                 // Complex expression → static const
                 self.write(&format!("static const {} {} = ", c_type, node.name));
@@ -19564,6 +19571,25 @@ impl CCodegen {
     fn gen_c_expr(&mut self, node: &Node) {
         match node.kind {
             NodeKind::ExprLiteral => {
+                // The lexer strips the surrounding quotes and stores the raw
+                // text, tagging the node `extra_kind == "string"`. Zig reads
+                // that tag (W560), Verilog reads it, the typechecker reads it
+                // -- and this emitter never did, so every string literal was
+                // written back as a bare identifier:
+                //
+                //     let s = "hello world"      ->  __auto_type s = hello world;
+                //     const NAME : str = "trinity" -> #define NAME trinity
+                //
+                // The second is worse than a compile error: a `#define` of a
+                // bare word is valid C, so it lands in the output and fails
+                // wherever it is used, or silently expands to something else.
+                //
+                // The lexer UNESCAPES as it reads, so the value here holds real
+                // newlines and quotes; they have to be written back escaped.
+                if node.extra_kind == "string" {
+                    self.write(&format!("\"{}\"", Codegen::zig_escape(&node.value)));
+                    return;
+                }
                 // Zig and Rust write `100_000_000`; C does not. The separator
                 // reached the output verbatim and `cc` reads it as a suffix:
                 // `invalid suffix '_000_000' on integer constant`. 97 lines
@@ -23963,6 +23989,14 @@ impl RustCodegen {
 
     fn expr_to_rust(&self, node: &Node) -> String {
         match node.kind {
+            // Same hole as the C emitter had, in the same place: the lexer's
+            // `extra_kind == "string"` tag is on the node and this arm returned
+            // the raw value, so `let s = "hello world"` became
+            // `let s = hello world;` and `const NAME : str = "trinity"` became
+            // `pub const NAME: String = trinity;`.
+            NodeKind::ExprLiteral if node.extra_kind == "string" => {
+                format!("\"{}\"", Codegen::zig_escape(&node.value))
+            }
             NodeKind::ExprLiteral => node.value.clone(),
             NodeKind::ExprIdentifier => node.name.clone(),
             NodeKind::ExprBinary => {
diff --git a/bootstrap/stage0/FROZEN_HASH b/bootstrap/stage0/FROZEN_HASH
index 299354069..f9a52b321 100644
--- a/bootstrap/stage0/FROZEN_HASH
+++ b/bootstrap/stage0/FROZEN_HASH
@@ -1 +1 @@
-69d5f0a49f872ffd608be86df0423f4c4df0f2cd30bf5f1e705eba52adffa04e
+4eccc2f5d22862da1ff78f07c76d232814c87af70a3927c9a997e603afbae31c

The change looks correct and worth landing on its own: gen_c_expr and
expr_to_rust never read the lexer's extra_kind == "string" tag, so
const NAME : str = "trinity" emitted #define NAME trinity — a #define of a
bare word, which is valid C and therefore worse than an error. Whoever owns it
should reapply it; I am not landing somebody else's compiler change under my name.

Measured, so the confusion does not repeat: with a release build of the branch
carrying the swept-in change, tri seals drift read 152 drifted seals against
master's 0, and seal-coverage went red on the pull request. After the revert
it reads 0. The drift was the emitter change, not the one-line test fix.

[gHashTag]

Closed by #2973 from the session that owns the file, with the same AtomicUsize repair. tri harness scratch --gate reads none and exits 0 on master at 23b006853. My #2969 is closed as superseded — the overlap is theirs.

The swept-in emitter work recovered above has also landed on its own, as #2971.