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)
(cherry picked from commit 0d94532df9)
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)
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.
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
1) Generate SHAPE_POLY_SET triangulation by outline so they can be
shared between connectivity system and other clients.
2) Don't add items to connectivity when reading board; we're going
to do a total rebuild anyway.
3) Use multithreading when caching triangulation.
This was leaking windows headers and partial wx headers to 1084 compilation units......
This also means math/util.h is leaking to 1084 compilation units which seems a bit high too.
CHANGED: when pad net assignments are changed in a conflicting way (i.e.,
tracks exist that short out more than one net after the change,
track nets will be updated to the net with the most pads).
Fixes https://gitlab.com/kicad/code/kicad/-/issues/7929
Jeff Young
Seth Hillbrand
Alex
Marek Roszko
Jon Evans
Ian McInerney