We have a break somewhere in the connectivity that doesn't fully process
connections but the current code seems to catch these by forcing a
top-down & bottom-up calculation
Fixes https://gitlab.com/kicad/code/kicad/-/issues/14818
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 RegressionZoneFillTests handle issues that are resolved by the zone
filler, so Clipper2 problematic fill belongs there. Otherwise, the
remaining tests should not refill the zones before running DRC because
we expect the DRC to catch errors without needing a refill
Aliases in bus resolution were being resolved without a path, making
them effectively global nets. This applies the corrected path to the
bus members and adds a QA to catch this error
The propagation is currently (maybe not needed) limited to the global
name that is the source of the change. We also need to propagate the
global name that is changed in case the global is set in a tree leaf and
not the root
Fixes https://gitlab.com/kicad/code/kicad/issues/14657
Adds QA checks to copper sliver tests. Adds the following checks:
- Dot product between two arms (quickly avoids checks for >90°)
- Checks the sliver is convex (area test)
- Eliminates minor slivers with angles that are approximately 0 and ones
with the opposite side width beneath a configurable level
- Updates Clipper2 to fix a couple of jagged edges on inflate
- Adds simplify during zone fill inflation to limit jaggies
Fixes https://gitlab.com/kicad/code/kicad/issues/14549
Previously, bus elements that were not instantiated as individual nets
could not connect to each other. This caused issues for complex
schematics where busses needed to connect to other busses with elements
that resolved to the same net names. Functionally, this means mixing
bus elements, which we will replace with first-class elements in version
8 but currently can only be accomplished either by using bus aliases and
this patch or by individually instantiating each bus element as a
local label
Fixes https://gitlab.com/kicad/code/kicad/issues/14300
Substantial elements following a divot should be at least as far in each
cardinal direction from the origin point in order to be considered
substantial. This catches cases where the "substantial" element is
actually a straight segment away from the divot
Fixes https://gitlab.com/kicad/code/kicad/issues/14130
Jeff Young
Seth Hillbrand
Roberto Fernandez Bautista
Alex Shvartzkop
Jon Evans
Thomas Pointhuber
jean-pierre charras
Marek Roszko