Fix extra net label in repro61, or remove trace#360
Open
js360000 wants to merge 1 commit into
Open
Conversation
When pins share a net only via net labels (no directConnections), the solver was still creating routed traces between them. This is the "trace jumping" bug shown in repro61 from tscircuit/core#1503: two capacitors with GND/VCC net labels on each pin end up with horizontal traces drawn between same-net pins, on top of the four expected labels. Root causes: 1. `getConnectivityMapFromInputProblem` passed `directConnMap.netMap` into the new `netConnMap` by reference. Subsequent `netConnMap.addConnections(...)` calls then mutated the "direct only" map too, so `dcConnMap` ended up containing net-only pins. Clone the netMap to keep the two views independent. 2. `MspConnectionPairSolver._step` looked up pins via `globalConnMap`, which by design unions direct + net connections. Switching to `dcConnMap` means net-only nets produce zero MSP pairs (and so zero routed traces). 3. `LongDistancePairSolver` iterated every net in `netConnMap` to fill in unconnected pins, including nets that exist only as labels — re-creating the bug at the pipeline level. It now skips any net that has no primary MSP pair: long-distance routing should only complete partially-routed nets, never invent traces for label-only nets. Tests: - New `tests/repros/repro61-net-label-only-no-trace.test.ts` locks in the fix at both the MSP and final-pipeline levels. - `MspConnectionPairSolver_repro1.test.ts` updated: GND (net-only, 3 pins) no longer produces 2 MSP pairs, so the expected count for the 2 directConnections + 1 net-only-GND input is 2, not 4. - 22 example snapshots regenerated to drop the spurious net-only traces. The visual change is consistent across them: net labels stand alone where there is no direct connection. Closes tscircuit#79
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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.
Summary
fix: don't route traces between net-label-only pins (#79)
When pins share a net only via net labels (no directConnections), the
solver was still creating routed traces between them. This is the
"trace jumping" bug shown in repro61 from tscircuit/core#1503: two
capacitors with GND/VCC net labels on each pin end up with horizontal
traces drawn between same-net pins, on top of the four expected labels.
Root causes:
getConnectivityMapFromInputProblempasseddirectConnMap.netMapinto the new
netConnMapby reference. SubsequentnetConnMap.addConnections(...)calls then mutated the "directonly" map too, so
dcConnMapended up containing net-only pins.Clone the netMap to keep the two views independent.
MspConnectionPairSolver._steplooked up pins viaglobalConnMap,which by design unions direct + net connections. Switching to
dcConnMapmeans net-only nets produce zero MSP pairs (and sozero routed traces).
LongDistancePairSolveriterated every net innetConnMapto fillin unconnected pins, including nets that exist only as labels —
re-creating the bug at the pipeline level. It now skips any net
that has no primary MSP pair: long-distance routing should only
complete partially-routed nets, never invent traces for label-only
nets.
Tests:
tests/repros/repro61-net-label-only-no-trace.test.tslocks inthe fix at both the MSP and final-pipeline levels.
MspConnectionPairSolver_repro1.test.tsupdated: GND (net-only,3 pins) no longer produces 2 MSP pairs, so the expected count for
the 2 directConnections + 1 net-only-GND input is 2, not 4.
traces. The visual change is consistent across them: net labels
stand alone where there is no direct connection.
Closes #79
Diff
Claim
/claim #79