Skip to content

tri mods orphan: a one-line #[path = ..] .. mod x; binds its own mod, not the next line (Closes #10936) - #10950

Merged
gHashTag merged 1 commit into
masterfrom
tri/orphan-one-line-path
Oct 19, 2026
Merged

gHashTag merged 1 commit into
masterfrom
tri/orphan-one-line-path

Conversation

@gHashTag

Copy link
Copy Markdown
Owner

Closes #10936. Repairs a red on master that #10819 (mine, lane B1 of #10522) introduced.

Cause. edges_from in cli/tri/src/modreach.rs reads a crate root line by line; a line starting with #[path = ".."] stored the path and skipped the rest of the line. #10819 wrote the SPICE and Zig mounts in the valid one-line form #[path = ".."] #[allow(..)] mod spice; // .., so mod spice; / mod zig; were never read and the stored path was applied to the next line's mod renum;: cli/tri/src/renum.rs (26 tests) was reported orphaned.

Fix. After a #[path] attribute, the rest of the same line (after the last ], before a // comment) is read for a mod declaration. The include! branch is written as one statement, so hand lines are +6 / -6 (own-language budget rc=0 locally).

Evidence.

  • cargo test --release -p tri modreach: 7 passed.
  • Negative control: the existing test a_path_attribute_does_not_carry_to_a_later_unrelated_mod now uses the one-line form and asserts the same-line binding; with the old parser it fails (panicked at cli/tri/src/modreach.rs:555).
  • tri mods orphan --gate on master with the fixed binary: cli/tri 54 files under src/, 54 compiled, 0 orphaned (+2 reached outside src/ via #[path]).

🤖 Generated with Claude Code

… not the next line's (Closes #10936)

#10819 wrote the SPICE and Zig mounts of cli/tri/src/main.rs as
`#[path = ".."] #[allow(..)] mod spice; // ..` on one line. edges_from()
stored the path and skipped the rest of the line, so `mod spice;` and
`mod zig;` were never read and the stored path landed on `mod renum;`:
renum.rs (26 tests) was reported orphaned and the reachability check went
red on master. After a #[path] attribute the rest of the same line is now
read for a `mod` declaration. The existing test
a_path_attribute_does_not_carry_to_a_later_unrelated_mod takes the
one-line form and asserts the same-line binding; with the old parser it
fails. `tri mods orphan --gate` on master: cli/tri 54 of 54 compiled, 0
orphaned. Hand lines +6/-6.

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

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-10-19 08:23:16 UTC

Summary

Status Count
Total Open PRs 50
PRs with Failing Checks 45
PRs with All Checks Green 5
READY 1
FAILING 45
PENDING 0
NO CHECKS YET 1

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

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=88b8cb73ceda != 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).

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.

[bug] master red: tri mods orphan reads a one-line #[path] .. mod x; as a path for the NEXT mod (renum.rs reported orphaned since #10819)

2 participants