Skip to content

fix(xilinx7): bitwalk prints usage and clean errors instead of panicking (Closes #6039) - #6073

Open
gHashTag wants to merge 1 commit into
masterfrom
fix/bitwalk-usage-6039
Open

gHashTag wants to merge 1 commit into
masterfrom
fix/bitwalk-usage-6039

Conversation

@gHashTag

@gHashTag gHashTag commented Oct 4, 2026

Copy link
Copy Markdown
Owner

Closes #6039.

Change

specs/xilinx7/bitwalk.rs only. No spec, generated module, seal or ledger is touched.

  • -h, --help, or no arguments print the usage and exit 0. --help anywhere on the line counts.
  • A wrong command line names what is wrong, prints the usage, and exits 2. That covers an unknown option, a mode with too few operands, --write without --part_file or --part_name, and a bad number (--cor0 OSCFSEL, --frame MIN).
  • A file that cannot be read or written prints bitwalk: PATH: <os error> and exits 1.

The usage text is the header comment at the top of bitwalk.rs, which already listed every mode. It is read with include_str!, so there is one copy and not two that can drift. One line was added to that header for -h/--help and the exit codes.

Each new check is a named bool (wants_help, unknown_flag, enough, in_and_out), as the issue asks.

Measured

Command-line matrix, 22 wrong command lines, run against the master binary and this one:

master (c107cd2) this PR
ends in a panic (exit 101) 21 / 22 0 / 22
expected exit code and message 0 / 22 22 / 22

The 22nd case on master is "no arguments", which printed nothing and exited 0.

Negative control: the same matrix with master as both binaries scores 0 / 22, so it does fail when nothing changed.

Good command lines unchanged, 4 / 4: a bare walk, --frame, --frames to a file and --cor0 to a file. Each has the same exit code and stdout as master, with timings normalised, and its output file is byte-identical.

Corpus checks with the new binary (x7.py from the xilinx7-bitstream-loop harness):

check result
--write vs xc7frames2bit 16 / 16 byte-identical
--write with the wrong part rc 1, 192 frames rejected, as on master
--fasm vs fasm2frames 22 / 22 byte-identical; refuse rows still refused, --strict still checked
fpga-assembler #49 gold 5 / 5

Not changed

  • An unknown IDCODE still stops at assert!(part != w::PARTS …) with a panic. That is a bad file, not a bad command line, and out of scope here.
  • Malformed file contents (the part database, tiles/segbits lines, IDCODE text) still .unwrap() their parses.
  • With no arguments the program used to exit 0 silently. It now prints the usage, still with exit 0.

Not measured

  • Callers outside the x7.py harness and the trinity-fpga tools that might parse bitwalk's stderr. Nothing on stdout changed for a good command line.
{
  "version": 1,
  "head_sha": "60ef0ea88149b1d33624b5fa5adbf5e6f5978d05",
  "summary": "bitwalk prints usage and clean errors instead of panicking on a wrong command line or an unreadable file.",
  "changes": [
    "-h, --help or no arguments print the usage (the file's own header comment, via include_str!) and exit 0.",
    "A wrong command line names the problem, prints the usage and exits 2; an unreadable or unwritable file prints the path and exits 1.",
    "Only specs/xilinx7/bitwalk.rs changes; no spec, generated module, seal or ledger edits."
  ],
  "tests": [
    {
      "command": "python3 bw_cli_matrix.py bitwalk-master bitwalk-new BIT",
      "status": "passed",
      "result": "22/22 wrong command lines give the expected exit code and message (master: 21/22 panicked with exit 101); 4/4 good command lines unchanged.",
      "evidence": "Matrix output; the same matrix with master as both binaries scores 0/22."
    },
    {
      "command": "X7_WT=<clone> python3 x7.py writer",
      "status": "passed",
      "result": "16/16 byte-identical to xc7frames2bit; the wrong-part case exits 1 with 192 frames rejected.",
      "evidence": "x7.py writer sweep output."
    },
    {
      "command": "X7_WT=<clone> python3 x7.py fasm",
      "status": "passed",
      "result": "22/22 byte-identical to fasm2frames; fpga-assembler #49 gold 5/5.",
      "evidence": "x7.py fasm sweep output."
    }
  ],
  "limitations": [
    "An unknown IDCODE still panics at the PARTS assert; malformed file contents still unwrap their parses.",
    "Callers outside the x7.py harness and the trinity-fpga tools were not surveyed."
  ],
  "tags": [
    "Engineering"
  ]
}

🤖 Generated with Claude Code

…ing (Closes #6039)

A wrong command line used to end in a Rust panic (exit 101) for 21 of 22
cases; running with no arguments printed nothing and exited 0.

- -h / --help, or no arguments: print the usage and exit 0. The usage text
  is the header comment of bitwalk.rs, read with include_str!, so there is
  one copy of it.
- A missing operand, an unknown option, or a malformed number: name it,
  print the usage, exit 2.
- A file that cannot be read or written: name the path and exit 1.

Good command lines are unchanged: the writer corpus stays 16/16
byte-identical to xc7frames2bit, the FASM corpus 22/22 to fasm2frames, and
fpga-assembler #49 gold 5/5.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Oct 4, 2026

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-10-04 13:16:51 UTC

Summary

Status Count
Total Open PRs 50
PRs with Failing Checks 39
PRs with All Checks Green 11
READY 10
FAILING 39
PENDING 0
NO CHECKS YET 0

These columns do not partition: 10 + 39 + 0 + 0 = 49, and there are 50 open PRs. A PR is being counted twice or not at all.

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=001c24236320 != manifest seal=87e5cbd3ad94.
    The committed NMSE numbers were certified against an older compiler.rs.
    Run scripts/reseal-check.sh locally for the two-step reseal command (advisory; not a merge gate).

@gHashTag

gHashTag commented Oct 4, 2026

Copy link
Copy Markdown
Owner Author

The two red checks here are red on master too, and neither reads bitwalk.rs:

  • Duplicate Body Ratchet (tools/dupe_scan.py) flags spec bodies under local_branch, nested_tail, ordinary_if and wide_tail, each copied twice and in no ledger. On master it has failed since 0886f014c (13:09 UTC today) and at the current head 2e852cf82. It passed at b1e3c159f, the commit before.
  • Spec Guards reports ring drift (ring-096-rust against specs/numeric/formats.t27, and others). On master it fails at 2e852cf82, 0886f014c and b1e3c159f.

This PR changes specs/xilinx7/bitwalk.rs and nothing else.

This was referenced Oct 4, 2026
This was referenced Oct 5, 2026

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bitwalk: --help and a missing file panic instead of printing usage or an error

1 participant