Skip to content

Add ObjectType-boxing infrastructure: getFields, spread, tuple cast#248

Merged
ASDAlexander77 merged 1 commit into
mainfrom
object-literal-boxing-infra
Jul 18, 2026
Merged

Add ObjectType-boxing infrastructure: getFields, spread, tuple cast#248
ASDAlexander77 merged 1 commit into
mainfrom
object-literal-boxing-infra

Conversation

@ASDAlexander77

Copy link
Copy Markdown
Owner

Summary

  • First of three staged PRs generalizing the generator-wrapper's BoxAsObject boxing (PR Box the generator wrapper as a heap-allocated ObjectType instead of a value tuple #245) so any object literal with methods can eventually be boxed as ObjectType (design in docs/object-literal-boxing-design.md) — this PR is pure infrastructure, no behavior change.
  • MLIRTypeHelper::getFields now looks through ObjectType to its storage type.
  • Object spread ({...obj}) handles a boxed ObjectType source (previously hit llvm_unreachable).
  • castTupleLikeVariants gained an ObjectType → tuple unboxing cast (needed for annotated declarations like const x: { m(): void } = someBoxedLiteral).

Test plan

  • New test test/tester/tests/00object_boxed_infra.ts exercises all three gaps via generator objects (the only literals boxed as ObjectType today), registered as both test-compile-00-objects-boxed-infra and test-jit-00-objects-boxed-infra.
  • Full suite green: 352/352 JIT + 356/356 AOT (ctest --test-dir <builddir> -C Debug -R "^test-jit-" / "^test-compile-" -j8).

🤖 Generated with Claude Code

… tuple cast

Generalizes the generator-wrapper's BoxAsObject boxing (PR #245) toward
supporting any object literal with methods: getFields now looks through
ObjectType to its storage type, object spread ({...obj}) handles a boxed
ObjectType source, and castTupleLikeVariants gained an ObjectType->tuple
unboxing cast. No behavior change for existing code paths; verified via
generator objects (the only literals boxed today) in new test
00object_boxed_infra.ts. Full suite: 352/352 JIT + 356/356 AOT.

See docs/object-literal-boxing-design.md for the full staged plan (this is
PR A of three).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@ASDAlexander77
ASDAlexander77 merged commit 9a7bd71 into main Jul 18, 2026
2 checks passed
@ASDAlexander77
ASDAlexander77 deleted the object-literal-boxing-infra branch July 18, 2026 17:27
ASDAlexander77 added a commit that referenced this pull request Jul 18, 2026
…ype (#249)

Generalizes the generator-wrapper's BoxAsObject boxing (PR #245, PR #248)
to any object literal with a method or accessor: mlirGen(ObjectLiteralExpression)
now boxes whenever oli.methodInfos/methodInfosWithCaptures is non-empty, not
just synthetic wrappers carrying the flag. Every alias of such a literal
(second binding, parameter, closure capture, array/object element) now
shares mutable state, matching JS semantics; pure-data literals keep value
(struct) semantics.

The flip itself is two lines, but exercising ObjectType through every path
that previously only saw tuples for method-bearing literals surfaced five
more missing ObjectType cases, each fixed:
- boxing seed value routed through mlirGenCreateTuple instead of the
  generic cast pipeline, avoiding a spurious "losing this reference" warning
- TupleGetSetAccessor's get/set now handles a pointer (ObjectType/RefType)
  operand via PropertyRefOp+LoadOp, not just ExtractPropertyOp
- castObjectToInterface gained the same field-type-coercion fallback
  castTupleToInterface already had (e.g. si32 vs number)
- element access (obj[Symbol.x]) dispatches ObjectType like Class/Interface
- generic intersection-type merge (D & M) and parameter inference look
  through ObjectType's storage type, same as MLIRTypeHelper::getFields

New test 00object_ref_semantics.ts covers alias mutation through bindings,
parameters, closures, array/object elements, accessors, globals, and
conditional-expression merges. Full suite green: 353/353 JIT + 357/357 AOT.

See docs/object-literal-boxing-design.md (PR B of three staged PRs).

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant