Repository navigation
[TS] Integrate computed class members without mixing symbol and string keys #575
Description
Current delivery (2026-10-17)
The bounded implementation is published for review, not merged:
- USVM [TS] Integrate computed class members with distinct symbol identity #578 at
d6c770ca5154cb55d2f3207374d5d0aa615d4fd8pins the public immutable JacoDB snapshot0fac32c8c5and makes the current method/field consumers respect symbol-versus-string identity. It also preserves the actual string key when the frontend emits%callfor a computed call. - Upstream [TS] Retain classes with constant computed member keys jacodb#448 at
0fac32c8c511c6228c3d6897262dc0924635af44is also open, not merged. Its optionalwellKnownSymbolmetadata and supported literal/numeric class keys are already consumed by the published USVM change. - Live CI is green at those exact heads: 7/7 checks for [TS] Integrate computed class members with distinct symbol identity #578 and 8/8 for JacoDB [TS] Correct symbolic value and storage semantics #448. The source/native regressions cover ordinary Counter methods and distinct string/symbol identities. The unchanged SegmentTree constructor/query probe returns symbolic
3, matching native execution.
This does not provide general Symbol storage or dispatch (#439), dynamic/shadowed computed keys, or complete class support. With #578 alone, the unchanged Matrix getter example exposed the mismatch recorded in #577. Published #595 instead makes that case explicitly unsupported; it does not execute the getter. Getter implementation remains #577.
The original bounded acceptance below is retained. The next delivery step for this issue is review/merge of the prepared dependency and consumer changes, rather than reimplementing their already-published code. No PR or issue was merged/closed by this status update.
Original report and acceptance (retained verbatim)
The two-phase PBT/USVM experiment (parent #345) needs the frontend fix in UnitTestBot/jacodb#448 (UnitTestBot/jacodb#447). That frontend retains literal computed class keys and a recognized intrinsic Symbol.iterator key, preserving symbol/string identity through optional wellKnownSymbol metadata in field and method signatures.
USVM currently compares member names as strings in virtual/static lookup, overload selection, field metadata and property-presence logic. Updating the dependency alone could conflate [Symbol.iterator] with the ordinary string "Symbol.iterator".
Bounded implementation:
- Update to a publicly resolvable immutable JacoDB snapshot containing the frontend fix.
- Keep ordinary string lookups separate from symbol-marked declarations across current consumers.
- Preserve explicit unsupported outcomes for symbol reads/writes/initialization not represented by existing runtime storage; do not silently use ordinary string storage or drop initializer effects.
- Prove ordinary methods on plain/literal-key/iterator Counter classes through source-level symbolic tests and native replay.
- Check original frozen Matrix and SegmentTree ordinary scenarios, preserving any next unsupported outcomes and source hashes.
General Symbol runtime and arbitrary symbol dispatch remain in #439. Path selector/priority queue changes are outside this issue.
Activity