lowering: Option equality over a concrete List type (ArrayList, RingList) is an internal error #381
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Context
Found while implementing #300 (
Bufferas aList). It reproduces on a published toolchain without any change of that issue, with the concrete list typesRingListandArrayList.Reproduction
torb runof this program (toolchainnightly-20261015,torb 0.1.0) stops withThe same happens for
Option<ArrayList<Int>>, and forOption<Buffer<Int>>onceBufferis declared aList(extend<Item> Buffer<Item> with List<Item>; it has anEqualsof its own before).Option<List<Int>>(the trait type, what a literal is) is not affected.Acceptance criteria
Option<T> == Option<T>(and!=) type checks, lowers and runs for a concreteT(ArrayList,RingList,Buffer) that implementsListand whoseEqualscomes fromextend<Item: Equals> List<Item> with Equals: the equality passes theListvalue toList.equalsas the witness expects it.Optionequality over anArrayListand aRingList, in the VM and natively.Notes
Equals.equalsinstance, not new syntax.if const Some(inner) = found { inner == other }).Refinement
docs/design/COLLECTIONS.mdsection 6e (Bufferis aList;Equalsis the one ofList), and the existing conformanceconcrete-collection-equality(direct==on concrete collections), extended to the same comparison through a generic derivedEquals.compiler/src/ir/lower/derive.trbfieldEqualitycallstraitMemberFunction(.., field.subject, "Equals", "equals")for a non-primitive field of the derivedEqualsofOption<T>;compiler/src/ir/witness.trbboxedReceiverOfis what makes the directRingList == RingListcall box both operands with theListtable. The failing call hands the unboxedRecordwhere the callee wantsObject(List<Int64>), so the wrapper is not applied (or not matched) on this path. Start with the IR dump of the reproduction and compare it toringList == ringList.fix(lowering): box the operands of a field's Equals through the extend targetandtest(conformance): Option equality over ArrayList, RingList and Buffer.Test
New conformance program
tests/conformance/option-list-equality.trb(+.expected,.allocationsviash tools/conformance.sh --update-budgets --filter option-list-equalityin CI-compatible form), in the style ofconcrete-collection-equality.trb:plus a
Buffer<Int>case intests/conformance/buffer-equality-show-hash.trb's style ifBufferis aListonmain(it is, section 6e). Runs in the VM and native as every conformance program does.lowering: Option equality over a List that is not an ArrayList is an internal error (RingList)to lowering: Option equality over a concrete List type (ArrayList, RingList) is an internal errororion referenced this issue2026-10-18 02:35:46 +00:00
[loop:torbscript] claim refine by session:loop-torbscript-20261019 until 2026-10-18T24:00Z
[loop:torbscript] decided by the loop: a compiler lowering fix with a conformance test, not a std workaround. Why: the same comparison written directly (
ringList == ringList) works through the box wrapper ofboxedReceiverOf, so the generic derivedEqualspath (fieldEqualityinderive.trb) must reach the same wrapper; fixing the lowering covers ArrayList, RingList and Buffer at once. Not seed-touching, one PR of two commits.[loop:torbscript] refine: acceptance criteria, design anchor (COLLECTIONS 6e), suspected location and the reproduction test are in the issue body; label
readyset. Worker: sonnet/medium, about 90k tokens. next: implement[loop:torbscript] claim implement by session:loop-torbscript-20261019 until 2026-10-19T05:00Z
[loop:torbscript] implement: the lowering fix is already on main.
torb irof the reproduction on nightly-20261015 shows the wrapper for theEqualsofListboxingselfbut notother;3bde36d0(Bytes is Buffer, after that nightly) madeboxedReceiverOfbox every parameter that isSelfof the trait, and the derivedequalsofOptiongoes through that same path. The first CI run of the new conformance program on main matched in native and VM (only the allocation budget placeholder was red; set to 105). So the PR is one commit,test(conformance): Option equality over ArrayList, RingList and Buffer, instead of the planned two (a lowering commit would be empty). PR #385, CI success (gates, tier A, bootstrap, pack the seed, pdisc), claim released, tokens ~150k, next: review (waiting on merge gate argus)[loop:torbscript] close: landed as
dc077652a0via #385 (the lowering fix itself came with3bde36d0). The push CI of main on that commit is red, but only on infrastructure:bootstrap (linux-x64)failed in the runner's checkout cache (shallow.lock: File exists, a stale git lock in the act cache), andgatesandpack the seedfailed after 0 to 5 s as its dependents; the PR run of the same tree was green. The loop cannot rerun a workflow through the API; the next push to main reruns it. Next: done, main CI waiting (runner cache lock)