Closed general

connect-pad-missing should be a hard error: generate emits dead wiring on pin/pad name mismatch and reports Lint PASSED

John Lauer · 2mo ago ·closed by John Lauer

connect-pad-missing should be a hard ERROR, not a warning - generate shipped dead wiring as "Lint PASSED, 0 errors"

Found while adopting adom-lbr as the Fusion bridge's only converter (fusion-bridge#43), testing the pin-number-vs-pad-name mismatch case.

Repro

A symbol numbered 1/2 against a footprint whose pads are named A1/B2 (the BGA-style break of the pin-number == pad-name convention):

adom-lbr generate --sym mismatch.kicad_sym --fp mismatch.kicad_mod -o mismatch.lbr
  LINT WARN: [connect-pad-missing] Connect references pad '1' which doesn't exist in the package
  LINT WARN: [connect-pad-missing] Connect references pad '2' which doesn't exist in the package
  OK: Generated mismatch.lbr (2 pins, 5760 bytes)
  HINT: Lint PASSED with 0 error(s), 2 warning(s)

The emitted library:

<smd name="A1" .../> <smd name="B2" .../>
<connect gate="G$1" pin="IN" pad="1"/>   <!-- pad "1" does not exist -->
<connect gate="G$1" pin="OUT" pad="2"/>  <!-- pad "2" does not exist -->

Why this severity is dangerous

Dead wiring is invisible to every downstream check that looks at renderings: the symbol, footprint and 3D all display perfectly, and the Library Manager's ganged view just quietly shows no pin connections. A part with broken connects photographs exactly like a working one - it fails only when someone routes a board with it, which is the most expensive possible place to discover it.

Your own lint taxonomy already treats empty-connects as fatal ("Fusion cannot use this component"). Connects that reference nonexistent pads are strictly worse than no connects - they look present while connecting nothing - so they deserve at least the same severity.

Asks

  1. Promote connect-pad-missing (and the symmetric missing-pin case) from WARN to ERROR, so generate exits 2 instead of writing the file.
  2. When the identity join fails (pin numbers do not match pad names), REFUSE with the two name sets side by side rather than emitting guessed connects - a caller can then supply an explicit mapping. Guessing by order on an IC is silently wrong wiring.

The Fusion bridge now guards this independently (fusion_prove_library checks connect referential integrity offline and refuses proven on dead wiring), so nothing is blocked on this - filing because generate's output is consumed by more callers than us.

1 Reply

John Lauer · 2mo ago

Verified fixed in 2.9.0 and closing. My original repro (a symbol wired to pads "1"/"2" over a footprint whose pads are "A1"/"B2") now fails validation instead of passing with warnings:

$ adom-lbr validate mismatch.lbr
FAIL: mismatch.lbr has 2 error(s)
  [connect-pad-unresolved] pin "IN" -> pad "1" (no such pad in package 'MISMATCH';
    unreferenced pads in package: A1, B2). Symbol pin numbers and footprint pad names
    disagree for this part: supply a pin map (generate --pin-map) or rename the pad...

The error text teaching the pin-map remedy at the moment of failure is exactly right - that is datasheet knowledge no converter can infer, and the message says so.

This matters more now than when I filed it: with conversion moving to authoring time (fusion-bridge 1.9.123, adom-bridge#92) the published .lbr is the contract every viewer's Fusion consumes, so dead wiring caught at publish never reaches a single user. fusion-bridge keeps its own connects check as the runtime backstop in the four-frame proof, but Ray's ferrite-bead-footprint story on adom-bridge#92 shows this lint doing its real job: a plausible artifact refused loudly instead of shipped silently. Thanks Ray.

Log in to reply.