Repository navigation
ESM module-init code is lowered with is_strict_fn: false — top-level strictness is wrong for some lowerings #9423
Description
Activity
- added a commit that references this issue
on Sep 2, 2026 Fixed by PR #9458:
Module::init_is_strictis set besidemodule_strict, read at both entry sites and threaded into outlined chunks — and joins the module stable hash so a cached sloppy compile can't be reused for a strict module.test_gap_9423_module_init_strictness.ts. Verified on main0a1c137d90with a fresh build: fixture byte-identical tonode --experimental-strip-types(stdout, stderr, and exit code).
Module top-levelthisis deliberately out of scope (Expr::ModuleTopThisis a module-goal decision that never consults strictness; it still diverges from node).
Module-init code is lowered with
is_strict_fn: falseeven for an ESM, which is always strict (crates/perry-codegen/src/codegen/entry.rs:825and:1537; deliberate perentry_outline.rs:677).It happens not to bite #9394 because
a[i] = vlowers toExpr::PutValueSet, which carries the realctx.current_strict. But anyExpr::IndexSetproduced by a different lowering —forheads, destructuring — reads the wrong strictness at module top level, so a rejected write there will silently no-op in code that is specified to throw.No end-to-end reproducer yet; this is a latent correctness hazard found by reading the strictness plumbing while fixing #9394, and it is filed so the next person touching module-init lowering knows the flag is not trustworthy there.
Worth pairing with #(the strict ordinary-object write issue filed alongside this one), since both are about strictness not reaching a store site.