test(next): stop the App Route dylib gate pinning the text backend

[proggeramlug]

What

tests/test_next_app_route_dylib.sh:176 pinned

PERRY_LLVM_INPROCESS="${PERRY_LLVM_INPROCESS:-0}" \

so the production App Route dylib gate compiled its fixture through the text transport, not the native in-process path that is the default. And ${VAR:-0} cannot express "unset" — passing PERRY_LLVM_INPROCESS= or any other value still sets the variable — so no invocation of this gate could exercise the shipped configuration. The nightly next-app-route workflow has been green on a backend users do not get.

This is the fourth shape from CLAUDE.md's "Four ways a gate can be unable to fail": the job runs, it is genuinely green, and its subject never ran.

Why it was there, and why it should go now

The pin was correct when it was written: #8228 made the native path unable to compile five of this fixture's modules (insertelement <2 x i64> had no case in the dialect reader, so the biggest modules — the ones split across codegen units — failed with bad binary op). #8241 fixed that and is merged. The pin now only hides the backend under test.

The variable is forwarded only when the caller sets it, so an explicit backend remains selectable for a bisection:

unset   → PERRY_LLVM_INPROCESS not in the child env (compiler default)
=native → forwarded verbatim

Evidence

Measured on 183d30c53a (bench mini, M1, Node 26.5.1, clang/opt 22.1.8) before writing this, as part of the #8040 native-path acceptance run:

• The app compiles on the native backend: 104/104 modules, Wrote shared library: next-app.dylib (87,475,088 B — against 203 MB via the text path).
• The gate passes 100/100 verifier repetitions, twice (10 cold processes × 10 passes each), 0 TypeError: value is not a function, 0 E180, 0 generated handler bypassed routeModule.handle.
• The backend is asserted live, not assumed: freeze/LLVM pipeline started — emitted only by native_emit::compile_module_units_native — appears 5× per native compile log (chunks/2.js 3 units, chunks/430.js 6, jsonwebtoken 2, app-page.runtime.prod.js 10, app-route.runtime.prod.js 4) and 0× on the text path. Those are exactly the five modules [codegen] In-process LLVM backend fails the 5 biggest Next App Route modules on current main (silent per-module failure; regression in 3c95020f8..07c8040bf) #8228 could not compile.

Full run: #8040 (comment)

Note for reviewers

This makes the nightly gate slower and stricter — the native path took 15–17 min per gate run here versus the text path's, and it will now go red if the native backend regresses on these five split modules. That is the intent: it is the only gate in the tree that compiles a real production Next bundle through the split-module native path.

No version bump. Refs #8040, #8228.

Summary by CodeRabbit

• Bug Fixes

  • Updated the Next.js App Route compilation check to use the compiler’s default native backend.
  • Explicit backend configuration remains supported when provided.

• Documentation

  • Added changelog details covering native-backend validation and pipeline results.

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 1a8b0c3a-f5e4-42be-92dc-15034e0c0059

📥 Commits

Reviewing files that changed from the base of the PR and between c34146d and b40577c.

📒 Files selected for processing (1)

• changelog.d/8274-next-gate-native-backend.md

---

📝 Walkthrough

Walkthrough

The Next.js App Route dylib gate now uses the native backend by default. It forwards PERRY_LLVM_INPROCESS only when explicitly set and documents the verification results.

Changes

Next.js native backend gate

Layer / File(s)	Summary
Native backend selection tests/test_next_app_route_dylib.sh, changelog.d/8274-next-gate-native-backend.md	The gate no longer sets PERRY_LLVM_INPROCESS=0 by default. It forwards explicit overrides and documents native and text backend verification results.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• PerryTS/perry#7339: Implemented the native in-process LLVM backend and its compilation paths.
• PerryTS/perry#8082: Introduced the Next.js App Route dylib gate backend configuration.
• PerryTS/perry#8161: Introduced the test gate updated by this change.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the main change: removing the App Route dylib gate's forced text-backend selection.
Description check	✅ Passed	The description clearly explains the change, rationale, affected gate, related issues, and detailed validation evidence, although it omits the template headings and checklist.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/8040-gate-native-backend

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[proggeramlug]

Merging. This is the payoff for #8241, and the diagnosis is exactly right.

The ${VAR:-0} point is the important one. A default-expansion cannot express "unset", so every invocation of this gate — including one passing PERRY_LLVM_INPROCESS= explicitly — set the variable and took the text transport. The nightly has been green on a backend users do not get. That is CLAUDE.md's fourth shape verbatim: the job runs, it is genuinely green, and its subject never ran.

I verified the replacement idiom rather than eyeballing it, since a conditional env-forward is easy to get subtly wrong:

caller	child env
unset	PERRY_LLVM_INPROCESS absent — 0 occurrences
=native	PERRY_LLVM_INPROCESS=native
=0	PERRY_LLVM_INPROCESS=0

So the default run exercises the shipped configuration and a bisection can still pin either backend explicitly. Both properties hold.

The sequencing is right too. The pin was correct when written — #8228 meant the native path could not compile five of this fixture's modules, because insertelement <2 x i64> had no case in the dialect reader and the biggest modules are exactly the ones split across codegen units. #8241 fixed that and is merged, so the pin now only hides the thing under test. Removing it in a separate, explained change rather than silently inside #8241 is the better order.

One expectation to set: this gate can now legitimately go red, because it is finally testing the default. If it does, that is the instrument working, not a regression from this PR — treat a red here as information about the native path.

One fix pushed: the changelog fragment was named 8259-next-gate-native-backend.md. #8259 is a different issue, already closed by #8265, and fragment filenames are PR-keyed so in-flight PRs never collide. Renamed to 8274-.