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)
The existing flag was never read anyway, and it's only the DRAGGER
that knows that the starting state is already colliding and that we
need to force mark-obstacles mode.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/8641
Graphic shapes (excluding text) can now have nets when on
copper layers. Shapes behave like tracks in that they will
pick up nets from connected pads, and follow track opacity
settings.
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....)
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.
- 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
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)