gnetlist accepts only the first of identical input/output symbols

[KaiMartin]

This one just got me by surprise. If there is more than one copy of an input/output symbol in a schematic, current gnetlist takes the first and ignores all others. To reproduce:

1) untar the attached mini project in a directory

2) cd demo-hierarchy
The project contains a head and a child schematic. There are two input symbols called "in1" in the child schematic. One of them connects to resistor R1, the other to LED1. This input symbol is fed with net GND from the head schematics. The other side of LED and resistor are both connected to a single ouput symbol out11.

3) do
gsch2pcb hierarchy-demo-head.g2p

The netlist will look like this:
/--------------
SUB1/noname2 SUB1/LED1-1
Vcc SUB1/LED1-2 SUB1/R1-2
GND SUB1/R1-1
\---------------

Note: GND is exclusively connected to the resistor. The connection to the LED is missing. The LED is connected to a dangling noname net, instead.

Expected action: Treat all incidences of input/output symbols with the same uref as connected. (preferred)

Alternative if the above is for some reason not feasable: Issue a big, fat warning that some connections will be missing.

Work-around: Connect the input symbol to a local named net and use this net multiple times.

---<)kaimartin(>---

[KaiMartin (kmk-familieknaak)]

The Mini project above missed some symbols.
Please find attached a more selfcontained version.

---<)kaimartin(>---

[KaiMartin (kmk-familieknaak)]

I poked a bit in the source of netlist. This seems to be a consequence of the general rule that all symbols with the same uref are regarded to be the same object. The hierarchy crawling code in s_hierarchy.c sees only one instance.

How would a proper fix work?
At the moment, I see two alternatives:

a) Do not unite i/o port symbols in the internal representation of gnetlist. But how would the paser know, that a symbol is a port symbol? Gnetlist relies heavily on the ability to go over all components. Would these loops all be fine with duplicate urefs?

b) This is a case of overloading the uref attribute with a meaning it is not designed to. There are more conflicts with potentially nasty side effects. Imagine a sub sheet pin called "R1". The hierarchy code might try to connect to the resistor rather than to the i/o symbol. Since duplicate urefs are explicitely allowed, DRC checks would not catch this.
An alternative way to mark-up an i/o symbol would do away with these traps. Say, an attribute "io_port=portname". But the symbol would still need a unique uref. What happens, if a symbol contains no uref attribute?

---<)kaimartin(>---