Latest Results
fix(es/typescript): Fold ambient const and ambient enum members
`tsc` treats `declare const x = 1` and members of `declare enum` that have
constant initializers as constant enum expressions, while erasing the
declarations themselves. The collection pass skipped everything ambient, so
both stayed opaque and the following auto-incremented members collapsed to
`undefined`.
Ambient consts now populate `const_vars` like any other const. Ambient enum
members go to a separate `ambient_enum_record` that only the evaluator
consults: `tsc` folds them inside enum and const initializers but never
rewrites runtime reads of the ambient object, and the inliner keys on
`enum_record` membership. Member initializers evaluate against the normal
enum record with an ambient fallback, so an ambient member can read an
earlier concrete enum, a const binding, and bare sibling references keep
resolving. Reads reached through type syntax stay opaque: the ambient
lookup is gated on `allow_const_var`, which evaluation clears when it
crosses an assertion, and ambient member initializers themselves follow
the const-initializer rule, so type syntax inside them removes constness. The split also reproduces enum merging: the ambient half of a
merged enum folds in initializers while its runtime reads stay untouched.
In an ambient `const enum` every member is constant, so the usual
auto-increment applies, and its id is registered in `const_enum` so it stays
resolvable under `tsEnumIsMutable`. In a plain ambient enum a member without
an initializer stays opaque, matching `tsc`. The mutable-enum guard applies
to this pass as well: ambient members reading a mutable enum stay opaque.baltasarblanco:fix/11715-ts-enum-const-var-folding fix(es/typescript): Fold ambient const and ambient enum members
`tsc` treats `declare const x = 1` and members of `declare enum` that have
constant initializers as constant enum expressions, while erasing the
declarations themselves. The collection pass skipped everything ambient, so
both stayed opaque and the following auto-incremented members collapsed to
`undefined`.
Ambient consts now populate `const_vars` like any other const. Ambient enum
members go to a separate `ambient_enum_record` that only the evaluator
consults: `tsc` folds them inside enum and const initializers but never
rewrites runtime reads of the ambient object, and the inliner keys on
`enum_record` membership. Member initializers evaluate against the normal
enum record with an ambient fallback, so an ambient member can read an
earlier concrete enum, a const binding, and bare sibling references keep
resolving. Reads reached through type syntax stay opaque: the ambient
lookup is gated on `allow_const_var`, which evaluation clears when it
crosses an assertion. The split also reproduces enum merging: the ambient half of a
merged enum folds in initializers while its runtime reads stay untouched.
In an ambient `const enum` every member is constant, so the usual
auto-increment applies, and its id is registered in `const_enum` so it stays
resolvable under `tsEnumIsMutable`. In a plain ambient enum a member without
an initializer stays opaque, matching `tsc`. The mutable-enum guard applies
to this pass as well: ambient members reading a mutable enum stay opaque.baltasarblanco:fix/11715-ts-enum-const-var-folding Latest Branches
0%
baltasarblanco:fix/11715-ts-enum-const-var-folding 0%
marcoshernanz:codex/fix-pure-callee-return-call 0%
marcoshernanz:codex/fix-cloned-iife-mangle-bindings © 2026 CodSpeed Technology