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
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....)
(cherry picked from commit 6f0d963683)
Rebased by Jeff Young <jeff@rokeby.ie> 5 April 2023
(Also includes a bug-fix for highlighting collisions with edge-cut
items.)
(cherry picked from commit bfbda978b8)
- 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
(cherry picked from commit 1283c4713f)
pickSingleItem() had a two-attempt algorithm, but the second attempt
was never made because we'd check for no hits before throwing out the
aAvoidItems.
The second attempt would fail anyway because QueryHoverItems() ignored
the aUseClearance flag when not idle, and didn't factor in the actual
clearance.
(cherry picked from commit d040690f60)
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)
Keeps parent information such as UUID and pad removal options for
elements that are just updated in routing rather than created fresh or
fully destroyed.
Fixes https://gitlab.com/kicad/code/kicad/issues/7460
Seneral
Tomasz Wlostowski
Jeff Young
Wayne Stambaugh
Alex
Mike Williams
jean-pierre charras
Jon Evans
Johannes Pfister
Seth Hillbrand
Marek Roszko