When moving a unique_ptr, you are actually passing the object, not a
reference to the object. So we either std::move with the bare
unique_ptr parameter or we pass a reference. But we should never pass
an rvalue reference for this or we'll make a copy without holding the
tracking (because it was moved)
Fixes https://gitlab.com/kicad/code/kicad/-/issues/16839
Some items only used within algorithms were never cached
Because they are hard to manually clean up
But caching them does help the algorithms a lot
So this solution is the best I can think of
(cherry picked from commit d29c07a663)
This was causing intermittent shove hiccups/freezes as RULE_RESOLVER::GetClearance() could return a bogus clearance value, taking
a cached value for an item that does not exist anymore. If the allocator/stack accidentally reclaimed such item's address - we were getting
very nasty and difficult to reproduce misbehaviours of the shove algorithm. Hopefully this patch fixes this. More info in the comments.
Note to self - I'm still not fully convinced I want PNS::ITEM pointers as the cache key, probably a unique counter would be better here.
About 1/3 of callers to Parent() don't care if they get the immediate
parent or not, about 1/3 want only the immediate parent, and about 1/3
want the hole parent's Parent().
I had earlier changed PNS::ITEM::HOLE to override Parent() and return
the hole parent's Parent(), but since the callers are pretty evenly
split I've reverted that and added BoardItem() for callers who want the
eventual BOARD_ITEM (whether a direct parent or a grandparent).
(Also removes a dead routine so I didn't have to figure out which of
the two it wanted....)
- LINEs now own their vias optionally (depending whether a LINE with its VIA belongs to a node)
- get rid of unique_ptr on the internal NODE::Add API (and also made it private)
- make sure stack pointers are not added to the node
- use rvalue reference for NODE::Add/NODE::Replace
Manually rebased by Jeff Young <jeff@rokeby.ie> 5 April 2023
- prerequisite for holes as first class objects code
- introduced the OWNABLE_ITEM interface that defines the owning container (NODE/other ITEM/ITEM_SET)
- simplified the ITEM_SET interface
- constified a lot of APIs (ownership/JOINT management) as a side effect
Rebased and cleaned up by Jeff Young <jeff@rokeby.ie> 5 April 2023
- some STL cover types removed
Each pad group is allowed to short nets with other pads in its group.
Legacy footprints with the "net tie" keyword hack will get a single
group auto-created with all the footprint's pads in it.
DRC and the router now allow a track to collide with copper graphic items
while entering a net-tie pad as long as the closest point in the collision
is within the pad.
DRC (and the footprint checker) now check for copper items in the
footprint shorting pads which are not in the same pad group.
Fixes https://gitlab.com/kicad/code/kicad/issues/2265
When we generate hulls, by default we subtract the clearance epsilon
to prevent false collisions in the router that wouldn't be flagged
by DRC. However, we need to use the actual hull with no epsilon
when generating hulls for pathfinding in the walkaround system.
Without this change, it is possible for the walkaround to generate
a valid-seeming path that results in a DRC violation, for example
when dragging a drag against a board edge.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/10536
Fixes https://gitlab.com/kicad/code/kicad/-/issues/11365
Fixes https://gitlab.com/kicad/code/kicad/-/issues/10710
(cherry picked from commit 2a91ba35c1)
The shove algorithm can't move the loose track ends. It always needs a via. In case of wide segments stitched with
a small via, the collision search finds only colliding segments and does not consider the via. This leads to frequent shove falilures
or 'choppy' behaviour when the head line only slightly overlaps with an end of a thick trace. This patch attempts at improving this behaviour
by considering the 'tiny via in wide segment' case explicitly.
Also checks the nets when checking for a pad being flashed on a particular
layer (so we don't end up thinking the currently-routing-collided track
is a connection).