Follow-up from #2612 (docs/plans/issue-2088.md), round 25's tightening of the round-17 coverage-check recipe after Greptile's P1 review comment.
Context
The mechanically-generated fixture matrix planned in WU-10 (docs/plans/issue-2088.md, "Fixture matrix" section) computes a three-term contract for each generated combination: invoked === true && escapes === 0 && !hasT1Evidence. invoked is obtained by executing the generated file under real Node and checking whether the tested property's handler actually runs.
The gap
For the round-17 coverage-check recipe (a var-kind for-of head decoy, target = content axis's own identifier), executing the generated file with container set to any of the nine function-shape values (function_declaration, arrow function, IIFE, async function, generator function, object method, class method, callback) never causes invoked to read true, because nothing in the axis definitions ensures the container itself gets called. The container's body — and the decoy/correlated-call machinery inside it — never runs unless something invokes it.
Executed check: the recipe flips escapes correctly (0 unfixed, 1 fixed) in all fifteen containers, since that's a purely static computation. But invoked only reads true for container = module and the five block-shaped containers (bare block, if block, try block, switch case, loop body), which execute unconditionally as part of ordinary top-level control flow. The nine function-shape containers need the matrix generator to also emit a call to the container itself (or otherwise guarantee its body executes) before the three-term contract becomes observable for those values.
Ask
When WU-10 is implemented, the matrix generator should ensure every container axis value's body is guaranteed to execute at runtime — e.g. by appending a trailing call/instantiation appropriate to the container kind (containerName() for a function declaration, invoking a returned/stored arrow function, new for a class, etc.) — so the invoked oracle is observable for every combination, not only six of the fifteen container values.
This does not affect the correctness of any existing fix; escapes is computed statically and is unaffected by whether the container is ever called. This is purely a completeness gap in the runtime-oracle side of the matrix's own test methodology.
Follow-up from #2612 (docs/plans/issue-2088.md), round 25's tightening of the round-17 coverage-check recipe after Greptile's P1 review comment.
Context
The mechanically-generated fixture matrix planned in WU-10 (docs/plans/issue-2088.md, "Fixture matrix" section) computes a three-term contract for each generated combination:
invoked === true && escapes === 0 && !hasT1Evidence.invokedis obtained by executing the generated file under real Node and checking whether the tested property's handler actually runs.The gap
For the round-17 coverage-check recipe (a
var-kind for-of head decoy, target = content axis's own identifier), executing the generated file withcontainerset to any of the nine function-shape values (function_declaration, arrow function, IIFE,async function, generator function, object method, class method, callback) never causesinvokedto readtrue, because nothing in the axis definitions ensures the container itself gets called. The container's body — and the decoy/correlated-call machinery inside it — never runs unless something invokes it.Executed check: the recipe flips
escapescorrectly (0 unfixed, 1 fixed) in all fifteen containers, since that's a purely static computation. Butinvokedonly readstrueforcontainer = moduleand the five block-shaped containers (bare block,ifblock,tryblock,switchcase, loop body), which execute unconditionally as part of ordinary top-level control flow. The nine function-shape containers need the matrix generator to also emit a call to the container itself (or otherwise guarantee its body executes) before the three-term contract becomes observable for those values.Ask
When WU-10 is implemented, the matrix generator should ensure every
containeraxis value's body is guaranteed to execute at runtime — e.g. by appending a trailing call/instantiation appropriate to the container kind (containerName()for a function declaration, invoking a returned/stored arrow function,newfor a class, etc.) — so theinvokedoracle is observable for every combination, not only six of the fifteen container values.This does not affect the correctness of any existing fix;
escapesis computed statically and is unaffected by whether the container is ever called. This is purely a completeness gap in the runtime-oracle side of the matrix's own test methodology.