Skip to content

starts_with("struct") has no word boundary: 'const dim = structure.len();' is counted as a struct definition, and 1180 is 1178 #3035

Description

@gHashTag

cli/tri/src/types_dup.rs decides that a line defines a struct with
after.trim().starts_with("struct")no word boundary. So

const dim = structure.len();

reads as a struct definition. Two such lines exist in
specs/demos/jones_topology_filter.t27 (lines 37 and 90).

The published figure moves

1180 → 1178. That number is quoted in docs/TYPE_CONFLICTS.md, by the types
ratchet, and in the UNCOVERED note in census.rs.

How it was found, which is the part worth keeping

Not by reading the code. A new --defs flag makes the census emit the
identity of every definition it counted, one per line, so a second reader can
subtract sets instead of comparing totals.

Both readers printed 1180. The totals agreed exactly. comm on the
identities showed a 2-for-2 swap — two rows only the census had, two rows
only the second reader had.

A total that agrees can hide an equal number of errors in both directions.
This is the same lesson as the 121-vs-123 gap closed by tri skill claims --numbers (#3019), met from the other side: there the totals disagreed and the
identities located it; here the totals agreed and only the identities could
have shown anything at all.

Not fixed here

The repair is a word boundary, and it moves a published number that several
consumers quote — so it wants its own change with the consumers updated in the
same commit, the way this repository re-seals in the commit that moved the
output. Filed rather than patched.

Refs #3019

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions