fix: don't create traces for net-label-only connections#132
Open
blessuselessk wants to merge 2 commits intotscircuit:mainfrom
Open
fix: don't create traces for net-label-only connections#132blessuselessk wants to merge 2 commits intotscircuit:mainfrom
blessuselessk wants to merge 2 commits intotscircuit:mainfrom
Conversation
Net connections (netConnections) represent virtual connections shown via net labels -- they should NOT produce physical traces. Only direct connections (directConnections) should generate MSP pairs and traces. Root cause: ConnectivityMap constructor stores its netMap argument by reference. When getConnectivityMapsFromInputProblem passed directConnMap.netMap to the netConnMap constructor, both maps shared the same underlying object. Calling netConnMap.addConnections() for net-label entries then polluted directConnMap.netMap too. Both MspConnectionPairSolver and LongDistancePairSolver used the polluted maps to create trace pairs for net-label-only pins. Three fixes: 1. getConnectivityMapsFromInputProblem: deep-clone netMap before passing to netConnMap constructor to prevent cross-contamination 2. MspConnectionPairSolver: queue only directConnMap net IDs and use dcConnMap (not globalConnMap) to find connected pins 3. LongDistancePairSolver: use directConnMap for candidate pair generation instead of netConnMap Fixes 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
1 participant
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.
/claim #79
Summary
Fixes #79 — Traces were incorrectly drawn between pins connected only via net labels (e.g., GND/VCC
netConnections). Net labels are meant to visually represent virtual connections without physical traces.Root cause:
ConnectivityMapstores itsnetMapconstructor argument by reference. IngetConnectivityMapsFromInputProblem,netConnMapwas constructed withdirectConnMap.netMap, so both maps shared the same underlying object. WhennetConnMap.addConnections()added net-label entries, they also appeared indirectConnMap.netMap. BothMspConnectionPairSolverandLongDistancePairSolverthen created trace pairs for net-label-only pins.Three fixes:
getConnectivityMapsFromInputProblem: Deep-clonenetMapbefore passing tonetConnMapconstructor to prevent cross-contaminationMspConnectionPairSolver: Queue onlydirectConnMapnet IDs and usedcConnMap(notglobalConnMap) to find connected pinsLongDistancePairSolver: UsedirectConnMapfor candidate pair generation instead ofnetConnMapTest plan
SchematicTracePipelineSolver_repro61.test.ts— two capacitors connected only via GND/VCC net labels, asserts 0 MSP pairs and net labels still placedMspConnectionPairSolver_repro1assertion (4 → 2 pairs, since GND was a netConnection)