Operator[] was creating an empty entry in the connectivity map,
fooling us into thinking the item had already been added.
Worryingly, this bug has been in there since 2017; a recent
change in teardrops just happened to expose it.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/14781
(cherry picked from commit 7e51077992)
In particular, when a CN_ITEM is freed set all its anchor's
item pointers to NULL. (The anchors have a separate
lifecycle due to being std::shared_ptrs.)
Hopefully fixes Sentry KICAD-KV.
(cherry picked from commit 0eac5c6748)
When drawing the ratsnest, we need to be careful to avoid accessing
CONN_ITEMs that have been changed by the underlying model. Checking for
dirty items instead of valid items will prevent us looking at data that
are out of date
Fixes https://gitlab.com/kicad/code/kicad/issues/14265
(cherry picked from commit 283770fc45)
- The C++ member now uses std::vector<KICAD_T>
- The Python side can use a single value or a list,
like in v6.
The std::vector translation is based on the v6 KICAD_T[]
translation.
When adding new data, we may have differing sizes of the dynamic
ratsnest and our local copy, so ensure that we are only referencing
elements that exist in both
This makes it clearer that the overrides are not inverses of each
other -- one overrides the flashing state and the other overrides
the connection state (to other zones, not to everything).
Also fixes a bug where we were failing to check the force-no-connect
for pads.
Internal routines have no need for locking the mutex they already own.
While external routines that want to recalculate the Ratsnest do need an
exclusive lock before being allowed access
Fixes https://gitlab.com/kicad/code/kicad/issues/13011
We call 'RecalculateRatsnest' in multiple locations, this will
invalidate various pointers needed by VIEW::Redraw(). When this is
called through the normal connectivity routines, we have the mutex
locked to prevent conflict but we've added more locations that update
just the Ratsnest. The std::adopt_lock should take over the existing
lock when needed
Fixes https://gitlab.com/kicad/code/kicad/issues/13011
Make sure that the connectivity has successfully completed before
attempting to merge segments. Also avoids reaching into the shared_ptr
if we don't need to
Fixes https://gitlab.com/kicad/code/kicad/issues/13639
(And doing so randomly as if the closer endpoint to the zone center
was the one without a pad then it would get marked as good, while if
it was the other way around we'd notch 2 connections for the pad end
and none for the other end.)
Fixes https://gitlab.com/kicad/code/kicad/issues/13420
Fixes an issue with `wait_for_tasks()` and adds a lower-overhead
`push_loop` helper. We replace our usage of `parallelize_loop` with
`push_loop` as we didn't use the multi-future vector return and don't
need the extra overhead.
Assigning to a reference to a std::shared_ptr does not update the
reference to a different std::shared_ptr; it changes what the
std::shared_ptr points to.
Fixes https://gitlab.com/kicad/code/kicad/issues/12968
1) The highest priority zone that a via/pad collides with "owns" its
connectivity state. Once set, lower priority zones cannot change it --
and in fact, if they would have connected to it are forced not to.
2) The connectivity state goes with the zone fill state, and therefore
must be saved in the file.
3) Display of remove-unconnected's pads is no longer done in GetViewLOD()
(which isn't called for selected items), and is instead done in PCB_PAINTER.
This allows us to draw the full pad in outline mode when a via/pad is
selected which would otherwise only show the hole.
4) Note that in some cases this will still generate DRC errors -- in
particular when a via nearly collides with a higher priority zone it
won't get "owned" by that zone and may therefore have insufficient
clearance if said zone concludes it's unconnected and a subsequent
(lower priority) zone connects to it (causing it to now become flashed).
Fixes https://gitlab.com/kicad/code/kicad/issues/11299
Removes some unneeded calculations and threads the remaining.
Threading was previously removed to avoid overhead issues with small
boards. This is no longer needed with the thread pool implementation
Fixes https://gitlab.com/kicad/code/kicad/issues/12131
1) Move a bunch of std::map's to std::unordered_map to get constant-time
look-ups
2) Lengthen progress-reporting intervals to spend more time doing work
and less time talking about it
3) Reverse order of SHAPE_LINE_CHAINs in thermal intersection checks to
make (much) better use of bbox caches
4) Don't re-generate bboxes we already have
5) Fix some autos that weren't by reference (and were therefore copying
large datasets)
6) Rename delta progressDelta so it's easier to search for in future
7) Get rid of a few more autos (because I don't like them)
8) Pass large items to lambdas by reference
Fixes https://gitlab.com/kicad/code/kicad/issues/12130
Thread pools are long-lasting executors that have close to zero overhead
when launching new jobs. This is advantageous over creating new threads
as we can use this for threading smalling jobs and smaller quanta. It
also avoids the heuristics needed to determine the optimal number of
threads to spawn
When building the connectivity database, we should not be using the
connectivity to check for shapes.
To make this deterministic, we introduce two flags (ALWAYS_FLASH and
NEVER_FLASH) that are used with connectivity building to determine
whether a pad is flashed for connectivity or not. ZONE <-> PAD/VIA
connectivity will be checked with ALWAYS_FLASHED and all other
connectivity will be checked with NEVER_FLASHED if they are marked for
potential annular ring removal. If they are not marked for removal,
they will be checked ALWAYS_FLASHED.
Fixes https://gitlab.com/kicad/code/kicad/issues/11114
Seth Hillbrand
Jeff Young
Salvador E. Tropea
Alex
Mike Williams
jean-pierre charras