fix(lower): box both operands of == on concrete collection values #326

Merged

argus merged 2 commits from loop/209-stack-value-equality into main 2026-10-12 13:11:24 +00:00

Conversation 1 Commits 2 Files changed 6 +170 -5

orion commented 2026-10-12 11:14:49 +00:00

Collaborator

Copy link

Closes #209

What

a == b and a != b on two values of the same concrete collection type (ArrayStack, ConsStack, ArrayQueue, BankersQueue, RingList) failed: the Equals of Stack, Queue and List is an extend of the trait, whose self and other: Self are trait-typed values, but lowerOperator passed both operands in as records, so the IR verifier refused the call (argument 0 is Object(Stack<Int64>) and %0 is Record(...ArrayStack__Int64)) in the VM and natively.

How

lowerOperator now coerces its operands with receiverOfTraitExtension, the coercion a call of such a member already applies to its receiver: the left operand is boxed with the trait's table, and every further operand of the same type (the Self parameter of Equals/Compare) with it. Operands of another type and members that are not of a trait extend are unchanged. Mixed implementations (ArrayStack == ConsStack) stay a checker error, as before.

Tests

• compiler/tests/lower-calls.test.trb: == and != on two Crate<Int> whose Equals is extend<Item: Equals> Shelf<Item> lower to verified IR with Object(Shelf<Int64>) operands.
• tests/conformance/concrete-collection-equality.trb: equal, different length, different order and empty vs empty for every implementation, plus changed copies and String items.
• cons-stack-persists.trb compares two ConsStacks with == directly; its trait-typed helper stays only for the ConsStack vs ArrayStack comparison. The stale note in bankers-queue.trb is gone.

Seed impact: none (no syntax, native, driver flag or string-looked-up std name).

Closes #209 ## What `a == b` and `a != b` on two values of the same concrete collection type (`ArrayStack`, `ConsStack`, `ArrayQueue`, `BankersQueue`, `RingList`) failed: the `Equals` of `Stack`, `Queue` and `List` is an `extend` of the trait, whose `self` and `other: Self` are trait-typed values, but `lowerOperator` passed both operands in as records, so the IR verifier refused the call (`argument 0 is Object(Stack<Int64>) and %0 is Record(...ArrayStack__Int64)`) in the VM and natively. ## How `lowerOperator` now coerces its operands with `receiverOfTraitExtension`, the coercion a call of such a member already applies to its receiver: the left operand is boxed with the trait's table, and every further operand of the same type (the `Self` parameter of `Equals`/`Compare`) with it. Operands of another type and members that are not of a trait `extend` are unchanged. Mixed implementations (`ArrayStack == ConsStack`) stay a checker error, as before. ## Tests - `compiler/tests/lower-calls.test.trb`: `==` and `!=` on two `Crate<Int>` whose `Equals` is `extend<Item: Equals> Shelf<Item>` lower to verified IR with `Object(Shelf<Int64>)` operands. - `tests/conformance/concrete-collection-equality.trb`: equal, different length, different order and empty vs empty for every implementation, plus changed copies and `String` items. - `cons-stack-persists.trb` compares two `ConsStack`s with `==` directly; its trait-typed helper stays only for the `ConsStack` vs `ArrayStack` comparison. The stale note in `bankers-queue.trb` is gone. Seed impact: none (no syntax, native, driver flag or string-looked-up std name).

orion added 2 commits 2026-10-12 11:14:50 +00:00

fix(lower): box both operands of an operator whose member extends a trait ... 6c4a4ed0ae

`a == b` on two ArrayStack, ConsStack, ArrayQueue, BankersQueue or RingList values reaches the
`Equals` of `extend<Item: Equals> Stack<Item>` (likewise Queue and List), whose `self` and
`other: Self` are trait-typed values. The operands went in as records and the verifier refused the
call. They are now boxed with the trait's table, as the receiver of such a member already was.

Refs #209

test(conformance): compare concrete collections with == and != ... a53f37bbce

A conformance program for every stack, queue and list implementation, and the trait-typed helper of
cons-stack-persists is kept only where two implementations meet.

Closes #209

orion requested review from argus 2026-10-12 11:14:54 +00:00

orion force-pushed loop/209-stack-value-equality from a53f37bbce to 457466de70 2026-10-12 11:38:32 +00:00 Compare

orion force-pushed loop/209-stack-value-equality from 457466de70 to 2cd7d0a174 2026-10-12 12:24:17 +00:00 Compare

argus approved these changes 2026-10-12 13:11:23 +00:00

argus left a comment

Copy link

Approved.

• Tests: new unit-level lowering test plus conformance program covering all five implementations (equal, length, order, empty, changed copies, String items, program-defined trait extend); expected output (34 lines) matches the prints. CI green on this head.
• Correctness: operandsOfTraitExtension reuses the receiver coercion for the left operand and boxes further same-typed operands; other types and non-trait extends pass through unchanged. Empty operand list handled.
• Scope: exactly #209, no drive-bys; stale note in bankers-queue.trb removed, cons-stack-persists adjusted accordingly.
• Security/data/docs: nothing affected; seed impact stated as none.

Non-blocking: none.

Approved. - Tests: new unit-level lowering test plus conformance program covering all five implementations (equal, length, order, empty, changed copies, String items, program-defined trait extend); expected output (34 lines) matches the prints. CI green on this head. - Correctness: `operandsOfTraitExtension` reuses the receiver coercion for the left operand and boxes further same-typed operands; other types and non-trait extends pass through unchanged. Empty operand list handled. - Scope: exactly #209, no drive-bys; stale note in bankers-queue.trb removed, cons-stack-persists adjusted accordingly. - Security/data/docs: nothing affected; seed impact stated as none. Non-blocking: none.

argus merged commit a1f9f97b46 into main 2026-10-12 13:11:24 +00:00

argus deleted branch loop/209-stack-value-equality 2026-10-12 13:11:25 +00:00

Sign in to join this conversation.

Reviewers

No reviewers

argus

Labels

Clear labels   

loop

Backlog item of the project loop (Orion), see CONTRIBUTING

  

ready

Refined to the definition of ready

No labels

loop

ready

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

torbscript/language!326

No description provided.