Elements such as zero-length lines might get into the connection map,
causing the system to process them twice. This can cause allocation
errors when both are performed at the same time
Fixes https://gitlab.com/kicad/code/kicad/issues/12278
All labels need to be attached to a net that has at least 2 pins in
order for this to be a valid net. To check for the existing pins, we
need to interate over all subgraphs in the net, counting pins
This is mostly to output the aliases sorted (for ease of VCS integration),
but also because a btree will be faster than hashing on a small dataset.
Fixes https://gitlab.com/kicad/code/kicad/issues/11890
To be connected, the label must have at least two pins on a subgraph
(or, in the case of a hierarchical label, two pins somewhere in its
connection)
Fixes https://gitlab.com/kicad/code/kicad/issues/7203
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
Pins that are explicitly connected in the schematic should not have an
"unconnected pin" ERC error. But stacked pins do not count as
explicitly connected because the schematic designer has not connected
them
(cherry picked from commit 865bb54591)
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
Now that we are dealing with individual connection elements that do not
update their connected elements as well, we can thread the update, just
being careful to guard any remaining updates (bus_enty/busLine) that
need reciprocal updating
Fixes https://gitlab.com/kicad/code/kicad/issues/10974
(cherry picked from commit 6a53e318e5)
If the SCH_ITEM has already been processed, the extra time needed to
iterated over the memberset and get the SCH_CONNECTION when we won't use
it is not neccesary.
Fixes https://gitlab.com/kicad/code/kicad/issues/10974
(cherry picked from commit 776a28a10e)
Normally, you will gain by resursing a nested loop only over the
pairs that are not already handled. In this case, however, you lose
time because you step outside of the cache by adding the reciprocal test
at each step.
Instead, we process one element at a time, keeping it cached and loop
over all other elements to add to the connection. This saves us about
75% of the time for larger loops (e.g. stacked power pins on a large
BGA)
Fixes https://gitlab.com/kicad/code/kicad/issues/10974
(cherry picked from commit 3a98eacdb9)
We want to shorting the processing time by marking symbols that have
already been processed. But we must avoid marking symbols that will not
be processed due to their other flags
Fixes https://gitlab.com/kicad/code/kicad/issues/11164
(cherry picked from commit 2208e0db16)
Needed to find bottlenecks in fns, so break out individual sections of
the massive function for easier understanding.
buildItemSubgraphs (one section of the previous function) would build
millions of connections that were never used as stacked pins created X!
connections. Also tested using sets instead of lists and keeping unique
lists to avoid flagging but none of these were as performant as using
flags to remember which items had already been processed.
Fixes https://gitlab.com/kicad/code/kicad/issues/10974
(cherry picked from commit 17b1b68ac7)
They don't define a KiCad string class, so the header file name was
somewhat misleading. But the fact that they didn't match definitely
made coding more difficult.
Certain situations can trigger the stale cleanup being run
on a bus that doesn't actually contain the stated member.
In this case we should just keep calm and carry on -- who knows
what netlist will be generated, but we shouldn't crash.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/8530
ADDED a new pin electrical type "free" for internally unconnected pins.
CHANGED the "unconnected" pin electrical type is now represented by
"no_connect" in files and netlists. (The legacy syntax is also accepted
in files.)
This way the net names can be inspected in eeschema and cross-probing works.
Testcases updated for the name changes
CHANGED: all unconnected pins are now included in the netlist with no_connect_ prefixes
This behavior provided shorter net names, but was confusing if
the user gives an explicit strong driver in the subsheet but not
one in the parent sheet.
Testcases updated for net name changes; connectivity is the same
Fixes https://gitlab.com/kicad/code/kicad/-/issues/4201
Depending on what order the subgraphs are processed in, it's
possible to hit a case where the parent sheet renames a bus
member before the bus neighbor renaming logic runs. In this
case, we don't want to apply the bus neighbor logic as it will
break connectivity to the parent sheet if that bus was not
also renamed (for example, if the hier ports only make net
connections and not bus connections)
Fixes https://gitlab.com/kicad/code/kicad/-/issues/6887
conflicts (more than one name for a net) is disabled.
This missing call was creating issues in tests that need a full connection
calculation, especially ercCheckFloatingWires()
Jon Evans
Jeff Young
Seth Hillbrand
jean-pierre charras
Alex
Marek Roszko
Wayne Stambaugh