merge queue: checking #2424 + #2473 together on master (5fcbf1f), stacked on #2415, #2419 and #2422 by mergify[bot] · Pull Request #2496 · celox-sim/celox

mergify · 2026-10-28T23:07:09Z

Note

This is a merge queue draft opened by Mergify. Nobody needs to act on it.
Mergify opened it for batch sound-pistou-nd74ne of the changes queue, to test #2424 and #2473 before they merge into master. Pushing to this branch or closing this pull request removes them from the queue.

What this draft tests

Mergify checks that #2424 and #2473 still pass CI once combined with everything queued ahead of them. CI runs on this draft's code, built in this order:

master at 5fcbf1f
the 3 pull requests queued ahead of this batch, listed below, which bring the tip to 140272d
#2424 + #2473, the pull requests of this batch, tested together as one tip

The check is speculative: it assumes the pull requests ahead will merge, so it starts without waiting for them.

🎉 Where it stands: checks passed

CI passed on this draft.

Follow the changes queue in the dashboard

What happens next

Once the pull requests ahead have merged, Mergify merges #2424 and #2473 into master and closes this draft.
If a pull request ahead fails or leaves the queue without merging, this batch is requeued and checked again on a new draft: these checks assumed it would merge.

Tip

A red check is not necessarily caused by this batch. These checks run on a tip that also carries the commits of the 3 pull requests ahead, so a failure here can come from them as much as from #2424 + #2473. See only this batch's changes.

Queued ahead of this batch

These pull requests entered the queue before this batch and are not part of it.

Metadata for CI tooling, read by mergify ci

---
all_scopes: false
checking_base_sha: 140272d1e5a1be6bc809340298753fd5593187a7
previous_check_retries: []
previous_failed_batches: []
pull_requests:
  - number: 2424
    scopes:
      - core
  - number: 2473
    scopes:
      - core
scopes:
  - core
...

1 scope

core

Required conditions of queue rule changes for merge

Required conditions to stay in the queue

Unpacked structures (IEEE 1800-2023 7.2) were rejected. A variable of an unpacked structure type is now a set of leaf variables, one per member that is not itself an unpacked structure, named by the member path (`s.a.b`). Each leaf keeps its member's type, so `string`, class handle, enumeration and 2-state or 4-state integral members behave like variables of those types, and the heap collector finds handle members through their own slots. A whole structure value is the concatenation of its leaves; it only lives within one evaluation. Supported: - module variables, procedural locals, and subroutine arguments of any direction and results (a structure argument is passed flat and copied into and out of its members' variables); - member reads and writes, whole assignment (also continuous, in `always_comb` and nonblocking), `==`, `!=`, `===`, `!==`, `?:`; - assignment patterns: positional, by member name, `default` (applied recursively to nested structures, 10.9.2) and typed `T'{...}`. Only patterns and values of the same structure type may be assigned (6.22.3); other operators, selects and casts of a whole structure are rejected. Ports, nets, parameters, class properties, arrays and container elements of an unpacked structure type, and members with unpacked dimensions or default values, are rejected with dedicated diagnostics; unpacked unions stay unsupported (#440). The concatenation parts of an assignment target now take the raw bits of the value, so a string member receives its handle instead of the bytes of an integral value. sv-tests chapter-7/structures/unpacked/basic now passes in both state modes. Icarus 13.0 does not support unpacked structures, Verilator 5.052 misapplies a nested `default`, and xezim 0.11.3 shows four defects on the new cases; these are retained as reviewed limitations and xezim review entries. Change-Id: I9a94c0cc4394766e17f949f72af405c2a3442b0f

A class property of an unpacked structure type was rejected. Its leaf members are now laid out as ordinary properties named by their member path (`orig.m_type`), so a `string` or class handle member is a handle property the collector traces, and a 4-state member keeps its X/Z bits. The class records the property and its structure-typed members (`Class::aggregates`) for lookup and hiding. `h.p.m` and an unqualified `p.m` inside a method resolve through the member path to the leaf property, including `h.p.m.q` through a handle member. A whole property `h.p` reads as the concatenation of its leaf loads; assigning it, from a pattern, a variable, another property, a conditional or a call, stores each leaf, evaluating the value once. Declaration initializers run in the constructor in declaration order, and a shallow copy copies the members. Methods returning a structure are now recognised when checking an assignment's type. Static, `rand` and `const` properties of an unpacked structure type stay unsupported with dedicated diagnostics. Icarus 13.0 still lacks unpacked structures; xezim 0.11.3 formats string members of such properties as packed values, which the review retains. Change-Id: I8d7ebe18fdf58ac33c7b1f2f76b7e27bf598b542

Queues, dynamic arrays and associative arrays of an unpacked structure type were rejected. A structure of at most 64 bits whose members are all 2-state or all 4-state and hold no handle is kept as its flat value, so the container's default element is the structure's default. Any other structure is held as an immutable heap record: `ObjectOp::Box` builds a record from the flat value on `push`, `insert` or an assignment, and `ObjectOp::Unbox` reads it back. Each leaf is a record field, so the collector traces string and handle members through the record's handle list, and 4-state members keep their X/Z bits. Record fields are `nullable`: the new `OBJECT_LOAD_NULLABLE` heap operation reads a null record as zeros without a fault, which is the default structure for a missing associative entry or a new dynamic array element. Records are not seeded, so they do not draw from the process RNG. `e.m` reads a member of an element `q[i]`, `aa[k]` or a popped element directly from the record or the flat value, including a handle member's properties (`q[0].orig.m_type.n`). Patterns, typed patterns and values of the structure type initialize elements. Comparing containers of records and sorting structures without `with` are rejected, as is writing a member of an element. Assignment patterns passed to a method argument now receive the formal's shape, which method calls taking a structure need. Change-Id: Iac820f46cbee8d792f4b0fbde28baccdd54ecf31

A dynamic container with several dynamic dimensions (`int m[string][$]`, `T m[C][C][E]`, `int grid[][]`) was rejected, as was an associative array indexed by a class (IEEE 1800-2023 7.4.5, 7.8.5), which UVM uses for its comparer, copier and recorder recursion state. An element of a container of containers is the inner container's handle. Containers are immutable heap values, so `m[a]` reads the inner container, an absent one being empty, and an update of an element's element, such as `m[a][b] = v`, `m[a].push_back(x)` or `m[a].delete(b)`, writes the updated inner container back into `m[a]`, and so on outwards. An element of container type takes a container value, so `grid[1] = new[3]` works. A class index is a handle; associative keys of object handles are traced by the heap collector (container parameter bit 46), so an object referred to only as a key stays alive. `foreach` and traversal methods take an index variable of the class type. sv-tests chapter-7/arrays/associative/class now passes in both state modes. Containers of fixed-size unpacked arrays stay unsupported. Icarus 13.0 rejects type-name indices; xezim 0.11.3 misreads two of the new cases, which the review retains. Change-Id: I54576c9fc206a0a46ff5a3e7a4782eaf5be449d3

A `ref` or `const ref` formal of unpacked structure type was rejected, which blocks UVM: `uvm_reg_adapter::reg2bus(const ref uvm_reg_bus_op rw)` and `bus2reg(..., ref uvm_reg_bus_op rw)` are elaborated with every `uvm_pkg`. A structure is a set of member variables, so its reference formal is now one reference per member, bound to the matching member of the actual (IEEE 1800-2023 13.5.2): writes through the formal are seen at once in both directions, also across task suspensions. - The analyzer records the members of a structure formal in `SubroutineParam::leaves`. A reference formal gets no copy-in or copy-out. The body that dispatches a virtual method forwards the members, so a call through a pure virtual method binds the override's members to the caller's. - Actuals: structure variables, members that are structures, class properties of structure type and their members. A scalar member of a structure is now also an ordinary reference actual (`bump(x.a)`). - Type equivalence (6.22.2) compares structure types by identity, also for containers of structures (`ref s_t q[$]`). - `const ref` writes, nonblocking writes and fork uses are checked per member. - The frontend binds each member like a scalar reference. A concatenation assignment to members bound to class properties writes temporaries in their place, so every destination position is taken before any write, then stores each property. A formal bound to a property and passed on to an `output` or `inout` structure argument copies each member back. - A receiver with a side effect (a pop, `$urandom`, a call) is rejected for a structure property actual, as for its whole reads, since each member would evaluate it again. Tests cover callee whole assignment, patterns, comparisons and passing on by reference or value; enumeration, string, class handle and 4-state members; handle members across heap collections; pure virtual `reg2bus`/`bus2reg`; and a task holding the reference across delays. Verilator 5.052 rejects two cases that bind a class property in a function that constructs an object (`%Error-IMPURE`, also with a scalar `ref`). xezim 0.11.3 shows its known copy semantics and padded string properties. Icarus does not support unpacked structures. The docs state that structure members may not be dynamic containers. Change-Id: I41a3098eb3b4359ca618580fb4de6bff25676be4

tignear and others added 10 commits October 29, 2026 06:16

Merge of #2415

7c509ff

Merge of #2419

f419cc5

Merge of #2422

140272d

Merge of #2424

981ff94

Merge of #2473

9f0d193

This was referenced Oct 28, 2026

feat(sv): support nested dynamic containers and class handle keys #2424

Merged

feat(sv): pass unpacked structures by reference #2473

Merged

mergify Bot closed this Oct 28, 2026

mergify Bot deleted the mergify/merge-queue/b1cd481070 branch October 28, 2026 23:20

Navigation Menu

Repository navigation

merge queue: checking #2424 + #2473 together on master (5fcbf1f), stacked on #2415, #2419 and #2422 - #2496

merge queue: checking #2424 + #2473 together on master (5fcbf1f), stacked on #2415, #2419 and #2422#2496
mergify[bot] wants to merge 10 commits into
masterfrom
mergify/merge-queue/b1cd481070

mergify Bot commented Oct 28, 2026 •

edited

Loading

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

mergify Bot commented Oct 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What this draft tests

🎉 Where it stands: checks passed

What happens next

Queued ahead of this batch

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

mergify Bot commented Oct 28, 2026 •

edited

Loading