Snapping happens to elements on copper layers but edge cuts is only
_virtually_ on copper layers. We need to set its routable flag off to
ensure we don't force-snap to the snap points
(cherry picked from commit c248993a84)
- Changes BOX2 size to extended coordinates.
- Adds BOX2ISafe to construct a BOX2I that will fit in int32.
- Adds more checks.
- Safer computations.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/17670
If the whole line shifts, we may have no points of the old tail in the
new line. In this case, we may not only not find the split point but we
may also have fewer points in the new line than were in the old head.
Clamping to the maximum potential point count prevents creating invalid
lines
Fixes https://gitlab.com/kicad/code/kicad/-/issues/16591
This was originally added to facilitate
https://bugs.launchpad.net/kicad/+bug/1777688 but the concern there was
that the layer kept changing when stopping on a via. We currently have
double-click as the force-finish option and the layer reverts to the
original layer on which you were routing. This should handle the
operation concern while still preserving shift as the modifier for grid
options
Fixes https://gitlab.com/kicad/code/kicad/-/issues/15828
The router needs to elimitate duplicate points but keep colinear
segments. This re-creates the partial routine from the old Simplify()
function
Fixes https://gitlab.com/kicad/code/kicad/-/issues/17582
Most of our pointers will share the top 32 or more bits of their pointer
addresses, making cache collisions highly likely. This uses a hash
combiner to mix the bits more effectively
The clearance epsilon should not be used to limit which force elements
we return in the query. Otherwise, we can drag elements into a
DRC-violating space
Fixes https://gitlab.com/kicad/code/kicad/-/issues/16293
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
Otherwise, the router might add bogus segments to the node. The root of the problem is somewhere in the logic that delivers aEndItem to ROUTER::Move() though - as the end item (in line placement mode at least) should always be an item within the same net as the head and not belonging to the current head...
Also fixes a bug in the router where the target length would
get trashed if set to maxLongLongInt. (We'd add the default
tolerance to it sending it negative.)
In particular, don't bail out if the starting seg is part
of a tuning pattern meander or a user-authored non-coupled
segment to get to a via or something).
Fixes https://gitlab.com/kicad/code/kicad/-/issues/16380