Recalculating creepeage every time we reported a new clearance error was
unneccesarily complex. Since the clearance errors are always straight
lines, we just need to calculate the closest approach and present that
segment
Fix handling of end point intersection case
Fix degenerate handling
Fix overflow cases
Simplify logic in SEG::Collide
Remove overly simplistic check for intersection
Add multiple QA regression tests
This appears to have always been [-360 .. 360], as some tests in
test_shape_arc.cpp have had negative values for a very long time.
Add tests on the start, end and central angle accessors to enforce
the documented normalizations.
First, fix the error limit check in drc_test_provider_edge_clearance.
Then, we rotate the final point incorrectly in SHAPE_ARC::Collide (need
negative angle). We were not checking this result in the QA, so add the
proper tests
This means that you can run just a single case from the command line,
for example:
`qa_pcbnew -t DRCCopperSliver/_0`
The case is also automatically printed as context.
This means that when isolating a specific defect in one case,
you can run only that one case, which is useful under debuggers
and also when using slow tools like valgrind.
Not all possibe tests are doing this, but they're easy to do
when needed (i.e. when you want to run just one case)
Having thread pool as its own singleton in the library meant that each
kiface had its own threadpool, leading to many multiples of the threads
being started. Placing a singleton class in PGM_BASE ensures that all
kifaces use the same thread pool.
The singleton class can be extended to provide single instance
guarantee for any element across kifaces
Recommendation is to avoid using the year nomenclature as this
information is already encoded in the git repo. Avoids needing to
repeatly update.
Also updates AUTHORS.txt from current repo with contributor names
If we are checking a point that is inline with multiple segments, we
were counting both the entry and exit as crossings, leading to points
inside a polygon being registered as outside. Changing the conditional
to only catch one crossing as required.
Adds a QA check to ensure that this remains fixed
Fixes https://gitlab.com/kicad/code/kicad/-/issues/18377
Come up with a plausible default chamfer size, rather
than prompting every time with a modal (and then you have
to handle when the chanfer doesn't fit). This could be
changed if it's more annoying this way. But if we had
proper edge-dragging in zones, probably would be better
than setting a chanfer manually.
Also fix the GetNeighbourIndexes which seems to have
always been broken (but is not actually used by anything at
present).
Relates-To: https://gitlab.com/kicad/code/kicad/-/issues/16771
This tells you the arguments when it fails.
BOOST_TEST is available in all our Boost.Test version.
Even if you didn't use it, these calls should have been
BOOST_TEST_EQUAL(A, B) which also tells you the
arguments on a test failure.
This has always been possible (especially through the properties
panel with large scales), but it's even easier if the transform
origin is near a manipulated corner.
Check and reject scales that result in an overflowed image box.
Makes it easier to reason about oval shapes in geometric terms.
For now, this isn't a SHAPE, but it could be (and it's a
fairly common primitive, so it could be useful, though the
obvious use (clearance) is equivalent to a SEG with a clearance,
which is already a function that exists.
In the core geometric types, this can provide some
useful optimisation opportunites.
As most trig functions and std::sqrt aren't constexpr
until C++26, anything that involves a vector length
can't be constexpr yet. But std::clamp and, importantly,
KiROUND are, which does allow quite a bit. And squared
sizes do work, as they are just multiplies, so size
comparisons work too.
The floating point equals-with-epsilon function can't
be directly made constexpr until C++23 (unless std::abs
is replaced with manual code, but that may then forgo
the use of intrinsics at runtime). And they're probably
not important to have at compile-time.
Add a few tests with static_asserts to show/prove that
some non-trivial operations can be done at compile time,
for example BOX2 merging.
This allows better value-semantics and const correctness.
This is a common method, as the Inflate method is
in-place:
BOX2I inflated = other;
// 'Inflated' is not inflated yet
inflated.Inflate( delta );
// Now it is inflated, but it's not const
This is annoying, as the 'inflated' box cannot easily
be made const. Instead:
const BOX2I inflated = other.GetInflated( delta );
If this is just 'int', BOX2D will not Inflate
as you might expect if given an non-integer parameter,
but will instead do a conversion.
Use coord_type, like the two-parameter Inflate method.
Add a test for this.
This is a pretty major rework of the snapping system.
The GRID_HELPERs now have a separate CONSTRUCTION_MANAGER
which handles some of the state involving "construction
geometry".
This is fed with 'extended' geometry (e.g. "infinite" lines from
segments) for use in generating things like intersection points.
It also handles adding this geoemtry to a GAL view item
(CONSTRUCTION_GEOM) for display to the user.
The process is:
* A TOOL creates a GRID_HELPER
* Optionally, it pre-loads a "persistent" batch of construction
geometry (e.g. for an item's original position)
* The grid helper finds useful snap 'anchors' as before, including
those involving the construction items.
* Other items on the board can be 'activated' by snapping to one
of their main points. Then, if it has construction geometry,
it will be added to the display. At most 2 items of this kind of
geometry are shown, plus the original item, to reduce avoid
too much clutter.
The dashed snap lines state machine is also handled in the
CONSTRUCTION_MANAGER and displayed in the CONSTRUCTION_GEOM item.
Put these in a separate header - they don't need to be available
whenever VECTOR2 is, but they are generic, reusable functions that
can have the corner cases defined and tested.
Issue raised by TomW, points included in new QA test where Simplify was
not properly removing colinear points.
Also removed TestSegmentHitFast() as the speed gains were minimal when
testing against the revised SEG::SquaredDistance routine in
TestSegmentHit()
This allows to see what the current snap point is, which is useful when
zoomed in, or the point is like the corner of a rounded pad where it's
"in free space" and might not be immediately obvious.
We are calculating the same value in two different ways. If there is an
off-by-one issue in our calculation along axis, this still means that it
was a direct hit on the line as seen in the unit test cases
Since Boost 1.64, you can use the boost_test_print_type
customisation point to provide test printing for types.
Move all test printing functions to this, and scrap the
fiddly Boost version handling to deal with older Boosts
(KiCad is now at minver 1.71).
