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
This commit partially reverts deb3cbf8. VIA and SOLID operator='s introduced in it do a good job but the cloning of holes in addHole() causes bogus collisions.
The diff-pair placer creates DIFF_PAIRs on the stack, which have
VIAs in them, which have HOLEs in them. The HOLEs get put in the
NODE's index, and we then crash later when doing a collision after
the stack variable has gone out of scope.
The stack variable is also copied while doing a search for "best",
and without the operator= definitions the "best" and the "original"
both think they own the HOLE.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/14852
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....)
(While we don't currently have holes without a parent pad or via, you
could imagine using HOLEs in the future to represent a hole in a first-class
board outline, so better not to build this assumption in.)
- 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
Simplification removes segments, so we might lose our valid index.
Ideally, we would simplify during the assembly or pass the input index
to the simplify routine to maintain the proper value.
Fixes https://gitlab.com/kicad/code/kicad/issues/12137
(cherry picked from commit 6c617d84ca)
Explanation:
- place a long segment A with something violating the rules close to its endpoint
- try to start routing in the 2/3 of the length of A (on the obstacle side)
- bummer - the router picks the nearest endpoint of A for the collision check (even though we don't care about this collision since we want to route far away from it)
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)
m_shapes now has two possible indices. The first one is populated if
the point is associated with an arc and the second index is populated
if the point is shared between two arcs.