Skip to content

feat(codegen): const-fold literal new Function bodies to native functions #1679

Description

@proggeramlug

Part of #1677. Blocked by #1678 — do not start until it is merged to main and parity-green.

Problem

When a new Function body is a compile-time constant string, an AOT compiler should turn it into a real native function instead of refusing it. This is true ahead-of-time eval and it builds the string → HIR plumbing reused by Phase 3.

Scope

For call sites the Phase 0 classifier marks const-foldable:

  • Resolve the body (and any param-name args) to constant strings via the existing const-prop pass.
  • Parse the body with SWC as a function body.
  • Lower it to HIR exactly as if the user had written the equivalent function literal.
  • Emit native code; replace the new Function call with a reference to it.

Note new Function has no access to local scope (globals only), so there is no closure capture to model — the lowered function is a plain top-level function referencing globals.

Covers: new Function('a','b','return a + b'), the (0, eval)('this')globalThis idiom, trivial generated accessors with literal bodies.

Acceptance criteria (the gate for Phase 2)

  • test-files for: literal single-expression body, multi-arg param names, indirect-eval globalThis idiom.
  • Byte-for-byte parity vs node --experimental-strip-types.
  • Non-constant bodies still fall through to the Phase 0 refusal (no regression).
  • Merged to main, lint clean, parity-green.

Out of scope

Library-generated (non-literal) body strings — those are Phase 3.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew capability or improvement

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions