specs/port: four ported types stop colliding with corpus types (types ratchet) - #5812
Merged
1 commit merged intoOct 4, 2026
Merged
1 commit merged into
1 commit merged into
Conversation
… ratchet) `tri types ratchet` was red on master at 17f0986: ledger 77, observed 81, four NEW conflicts from the 2026-10-03 trinity port batch. Rename the newer definition inside its own file, as #5504 did, instead of blessing the ledger: CounterState d_f19_test.t27 (#5797) -> F19CounterState CounterState d_slow_blink.t27 (#5798) -> SlowBlinkCounterState LRUCache gen_cache.t27 (#5794) -> GenLRUCache TestCase gen_test_runner.t27 (#5792) -> GenTestCase TestRunner gen_test_runner.t27 (#5792) -> GenTestRunner All four backends emit byte-identical output for each file once the new name is mapped back. Ledger, classification and TYPE_CONFLICTS.md are unchanged (none of the names was in them); ratchet CLEAN at 77, classified OK. No seal existed for any of the four specs. Closes #5810 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
This was referenced Oct 3, 2026
This was referenced Oct 4, 2026
gHashTag
added a commit
that referenced
this pull request
Oct 4, 2026
The three red checks on this PR (corpus ratchet types, emit-bitexact on specs/xilinx7/packets.t27, spec-guards) were measured on 2026-10-03 against a master that was red for the same reasons; #5812 and the packets fixes have since landed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
gHashTag
added a commit
that referenced
this pull request
Oct 4, 2026
#5853) * feat(tri pr ready): ask a check's own workflow when the commit window missed it `tri pr ready 5826` said CANNOT TELL (exit 3) on fpga-conformance: "did not run on any recent master commit". It had: master's newest run of FPGA E2E Build at e7ed379 failed that job, 21 commits back; the walk reads 15. Only for a failure neither the walk nor the merged-PR baseline observed: details_url -> run -> workflow -> its newest completed default-branch runs (page 10, page-fill guarded), read one at a time until a job of the same name reached success/failure/timed_out. Cancelled and skipped are passed over. Red there is pre-existing, green there is new here, nothing there stays NO BASELINE and says how far it looked. An API error leaves the check without a baseline: CANNOT TELL, never safe. The walk is unchanged. Real run: tri pr ready 5826 -> exit 0, citing e7ed379 and its age. 8 new tests (53 in prcheck), 7 mutations each red. Census: fetches moved 69 -> 72 lines, fetch sites 28 -> 31 (--paginate 7 -> 9, page-fill guarded 10 -> 11) -- the three new reads, every one complete or guarded; unguarded buckets unchanged. Blessed here. Closes #5837 Refs #5786 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * feat(tri pr ready): --why compares what a pre-existing failure printed A check red on master under the same NAME was called pre-existing, whatever its step printed. A pull request that adds a fifth conflicted type name to the Corpus ratchet read exactly like one that adds nothing. --why (off by default) fetches the failing step's own output from both jobs -- this pull request's and the one the baseline used -- masks timestamps, colour codes, durations, shas and long ids, and compares each side's last 60 lines against the other side's whole output. A line not found as itself is looked for by its shape (digits read as #): it is printed for a person, not judged, because a count moves when the cause does not (#5663: observed 78 vs 81, a subset of master's names). NEW REASON is exit 7; precedence 2 > 3 > 1 > 7 > 0; --merge refuses. Live: #5781 NEW REASON (+ ModuleInterface), exit 7; #5663 SAME REASON, fewer, exit 0; #5812 NEW REASON (another step), exit 7. Tests: 6 new in prcheck::why_tests + the verdict test now calls the real verdict_code (59 in prcheck). 16 mutations, each red. Census: fetches 72 -> 74 lines, 31 -> 33 fetch sites, --paginate 9 -> 11 (failing_jobs_on, failing_job_in_run). Blessed here. Closes #5852 Refs #5837 #5839 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #5810
Description
Corpus Ratchet, step "A type name may not gain a second definition", is red on master at17f09865a(run https://github.com/gHashTag/t27/actions/runs/37147322541):ledger 77 name(s), observed 81, four NEW conflicts. Every open PR inherits it.All four come from the 2026-10-03 batch of automated trinity ports (merged 18:31-18:33 UTC, each with this job already red).
tri types ratchetwalksspecs/only (notcompiler/), socompiler/*.t27'sTestCasedefinitions play no part.CounterStatespecs/port/fpga/vivado/uart_echo_top.t27:43{value: u32}specs/port/trinity/fpga/openxc7-synth/d_f19_test.t27:17{value: u32, cycles: u32}F19CounterStateCounterStatespecs/port/trinity/fpga/openxc7-synth/d_slow_blink.t27:29{value: [24]u32}SlowBlinkCounterStateLRUCachespecs/tri/collections/lru_cache.t27:13specs/port/trinity/src/tri/gen_cache.t27:3GenLRUCacheTestCasespecs/port/tools/wp18_gate_selfconsistent_selftest.t27:36specs/port/trinity/src/tri/gen_test_runner.t27:3GenTestCaseTestRunnerspecs/test_framework/runner.t27:90specs/port/trinity/src/tri/gen_test_runner.t27:8GenTestRunnerThe repair follows #5504 (Refs #5497): rename the newer definition inside its own file and leave the ledger alone. Nothing is blessed -- none of the four is a deliberate shared type; each pair is two unrelated concepts on one name. Function and test names (
LRUCache_init,TestRunner_run, ...) stay as ported, as #5504 leftBezierCurve_eval.The porter will not undo this:
tools/queen/feed_roadmap.pypick()skips any target that already exists or is already named by an issue, so these files are not regenerated.Changes
specs/port/trinity/fpga/openxc7-synth/d_f19_test.t27--CounterState->F19CounterState(every use in the file)specs/port/trinity/fpga/openxc7-synth/d_slow_blink.t27--CounterState->SlowBlinkCounterStatespecs/port/trinity/src/tri/gen_cache.t27--LRUCache->GenLRUCachespecs/port/trinity/src/tri/gen_test_runner.t27--TestCase->GenTestCase,TestRunner->GenTestRunnerdocs/now/2026-10-04-four-ported-types-stop-colliding-with-corpus-types.md-- NOW entrydocs/reports/type_conflicts.json,docs/reports/type_conflicts_classified.json,docs/TYPE_CONFLICTS.md(none of the four names was in them);.trinity/seals/(none of the four specs had a seal --t27c seal --verifyanswers "No saved seal found" -- and minting them is not this change:d_f19_test.t27andd_slow_blink.t27are bothmodule trinity_topand would write the sameopenxc7-synth_trinity_top.json); nothing undergen/.Testing
Fresh worktree off
origin/master(17f09865a);cargo build -p tri,cargo build --release -p t27c.Codegen equivalence: for each of the four files,
t27c gen,gen-rust,gen-candgen-verilogwere run on the pre-rename and post-rename copy. All 16 runs exit 0 both times, and the outputs are byte-identical once the new name is mapped back to the old one (the new names do appear in every output: 4 to 24 hits per file).L3:
grep -P '[^\x00-\x7F]'over the five touched files prints nothing.Review Notes
This PR turns the types step green; the
Corpus ratchet (expected-failure ledger)check will still be red, one step later. On master the step "Run the corpus ratchet" was skipped behind the types failure, so nobody has seen its verdict. Locally on this branch:None is caused by this change: two files are untouched, and
d_slow_blink.t27discards the same 182 tokens before and after the rename (parse-completeon isolated copies). All three landed in the same 2026-10-03 batch with this check already red. Causes: the two openxc7-synth ports write tests asvar (a, b) = f(...)tuple bindings, which the parser drops, so those test clauses (and oned_simple_ffinvariant) never reach codegen;packets.t27uses a C-stylefor (var i = 0; i < 37; i += 1)at line 137. They want a spec fix or a ledger entry with a reason, which is a separate decision from this one and is left out of this PR on purpose.Title deliberately not
fix(<compiler scope>)(tools/check_fix_carries_source.py): no compiler source changes.φ² + 1/φ² = 3 | TRINITY
🤖 Generated with Claude Code