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.
We were calculating the same thing in three locations and we missed
adding the clearance from the footprints in, resulting in bad fills and
missed drc errors (see QA addition)
The actions the router uses for via placement can be a combination of
enum values, so the actions must use an int parameter instead of the
enum type.
Fixes KICAD-2DS
Using a boolean argument just leads to a lot of trailing booleans in the
function calls and is not user friendly. Instead, introduce PostAction()
to send an action that runs after the coroutine (equivalent to passing
false or the default argument), and leave RunAction as the immediate
execution function.
Using std::any from C++17 allows for proper type handling in the
parameter field, removing the need for casting to void* and then casting
the void* to the desired type.
When routing and using layerNext (hotkey '+') to switch to next layer,
it will skip invisible layer, when click BUT_LEFT, the new line should
be in the same layer (visible layer)
Fixes https://gitlab.com/kicad/code/kicad/-/issues/14480
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.
The root cause was not removing the original (pre-dragging) via from the world, comparing the ITEM::Parent() pointers of the items was only hiding the main issue.
This also fixes the PNSViaCollisions test in the qa/ suite.