Files
scriptc/docs
Chris Tate cda76716a0 Enumerate each record in the key order its object literal wrote
Record shapes are interned by field set, and their key order was one table
per shape. When object literals of one shape wrote the keys in different
orders (`{ id, name }` and `{ name, id }`), every value enumerated in the
first type's order, and anonymous literal types got no warning.

- The key-order witness pass gives such a shape its orders
  (IrRecordShape.orderVariants, the declared table first) and a hidden
  number field, %order, that each value sets to the index of its order:
  a literal of explicit keys stores its own order, a copy from a shape
  with one order stores that order, and spreads, rest bindings and
  copies of values with orders read their source's index. Allocation
  zeroes the field, so checked conversions and runtime producers keep the
  table as before, and clones copy it.
- A write of an optional key a value lacks moves the key to the end of
  that value's order, as in Node: the orders include each order such
  writes reach, and the write site updates the index first, evaluating a
  receiver other than a binding once.
- Object.keys, Object.values, Object.entries, for-in, util.inspect,
  JSON.stringify, the record-to-dynamic conversion (structuredClone,
  postMessage, untyped views) and live record views branch on the index.
  The dynamic conversion and checked conversions leave the field out.
- A shape keeps its table, and SC6002 still reports its literals, when a
  construction's order cannot be traced: a spread of a value of unknown
  order, a clone that adds an optional key, a copy whose source is not a
  binding, or more than 16 orders.

Corpus 7122 to 7128 check each surface against Node.
2026-10-22 05:51:17 -05:00
..
2026-07-22 18:08:04 -05:00
2026-10-22 03:24:23 -05:00
2026-10-02 00:58:25 -05:00
2026-10-02 00:58:25 -05:00
2026-07-22 18:08:04 -05:00
2026-07-22 18:08:04 -05:00