Fix order-dependent port renaming; close gdstk backend gaps

[carloscl03]

Two commits. The first is a real bug in port_utils that affects the default
backend too; the second unblocks GLAYOUT_BACKEND=gdstk for the opamp.

Renaming ports depends on dict order

rename_component_ports renames in place — pops the old key and inserts the
new one on the same dict it just iterated:

for namepair in names_to_modify:
    if namepair[0] in custom_comp.ports.keys():
        portobj = custom_comp.ports.pop(namepair[0])
        custom_comp.ports[namepair[1]] = portobj

When a port renames onto a name another port still holds, that guard silently
skips it and one of the two is dropped. Which one survives depends on insertion
order.

rename_ports_by_orientation triggers this routinely: a mirrored port has
orientation 90 and legitimately renames _S -> _N onto a name still queued.
In diff_pair(gf180, width=3, fingers=4) that is 334 ports.

Same component, same port, orientation 90.0:

backend	result
gdsfactory	keeps bl_multiplier_0_source_S (90° is N, so this is wrong)
gdstk	gives bl_multiplier_0_source_N (correct)

add_df_labels then raises KeyError on the latter. It works under gdsfactory
by accident of ordering, not by construction.

Fix builds the renamed mapping first, then swaps it in.

diff_pair(gf180, width=3, fingers=4)
  before   4530 ports    gdstk: KeyError 'bl_multiplier_0_source_S'
  after    4864 ports    both backends identical

The 334 extra ports are the ones that were being dropped.

gdstk backend gaps

With the rename fixed, the opamp got further and hit four more gaps, found one
at a time:

1. Component.add() rejected a bare Component. gdsfactory accepts one and
   references it implicitly; several composite cells rely on that.
2. diff_pair_stackedcmirror imported rectangle straight from gdsfactory,
   bypassing the backend abstraction — the module already imports the backend's
   rectangle at module level.
3. ComponentReference.info held its own empty dict. mimcap_array writes
   info['netlist'] on the Component while opamp_twostage reads it back off
   the reference returned by <<; gdsfactory exposes the parent's info through
   the reference, so delegate.
4. Component.ref() took no arguments. opamp.py:155 calls
   ref(position=...).

Results

opamp(gf180, ...), same parameters as GLayout_Cells.ipynb cell 14:

backend	time	ports
gdsfactory	383.0 s	—
gdstk	55.5 s	99090

No regression: under gdsfactory, nmos(gf180, width=3, fingers=4) produces
3328 ports and 875 polygons before and after.

Note

This makes the fast backend usable; it does not address why the slow one is
slow. Profiling the opamp under gdsfactory shows 96% of runtime inside
pydantic validation, 6.3M serialization.py calls, and 1.85M Port objects
created — 93% of a transistor's ports belong to individual vias that are never
routed to. That is a port-model question, not something a compatibility fix
reaches.

[carloscl03]

Context on why this came up: #100's notebook check fails on
GLayout_Cells.ipynb, and main fails the same way — the opamp cell crosses
--cell-timeout 180 on slower runners (87 s on the runner that passed, so
roughly a 2x swing is enough to trip it).

Chasing that led here. With GLAYOUT_BACKEND=gdstk the same cell drops from
383 s to 55.5 s, which would take that check well clear of the limit rather
than leaving it near the edge. The gdstk backend could not build the opamp at
all before these fixes, so that number was not measurable until now.

So this does not fix #100's check directly, but it makes switching the notebook
job to the fast backend a viable option — likely more durable than raising the
timeout, since the current margin depends on which runner GitHub hands out.

[carloscl03]

Measured what this unblocks, in case it helps prioritise it.

The DRC and LVS workflows run the gdsfactory backend (CPython 3.10, gdsfactory 7.7 via install_requires), so gdstk has no CI coverage today. I tried building the gf180 cells on gdstk to see how far it is from being usable there.

On main, they do not build at all:

[ERROR] diff_pair: build failed        KeyError: 'bl_multiplier_0_source_S'
[ERROR] diff_pair_ibias: build failed  KeyError: 'br_multiplier_0_gate_S'

With this branch, the same command builds both and writes GDS and netlists — 0 errors. What is left is off-grid geometry (contact_OFFGRID, via1_OFFGRID, metal1_OFFGRID), which is what #104's snap-to-grid commit addresses.

So this is not only a fix for the alternative backend: together with #104 it is what would let the DRC/LVS workflows run on gdstk at all. Worth noting because on the runner that passed, the gdstk backend built the opamp cell in 55.5 s against 383 s on gdsfactory.

[carloscl03]

Heads-up for whoever merges this and #104: the two branches conflict, and the obvious resolution is the wrong one.

Both add to ComponentReference in src/glayout/backend/_gdstk.py. Two hunks:

1. __init__ — gdstk backend: close API gaps so the tutorials run #104 gives the reference its own self.info: dict = {}; this branch makes info a property delegating to the parent. Keeping both compiles and breaks silently: the assignment in __init__ calls the property setter, which does self.parent.info = {} and clears the target component's metadata on every placement. That includes info['netlist'], which mimcap_array writes and lvs_netgen reads back — so LVS stops finding the netlist, with no error to trace it by.

   Resolution: keep the property, drop the self.info = {} line, keep self._name from gdstk backend: close API gaps so the tutorials run #104.

2. __getitem__ (gdstk backend: close API gaps so the tutorials run #104) vs pprint_ports (this branch) — two distinct methods in the same place. Keep both.

Verified with the resolution applied, on top of main with #100, #103, #112 and #113 also merged:

cell	result
CapiMagics encoder	builds, 0 DRC violations
CapiMagics integrator	builds (fails to build without this PR), 8 violations
our LIF cell	builds, Netlists match under klayout LVS

Same numbers as the tree these were originally measured on, so the resolution does not change behaviour.

Happy to rebase this branch onto main once #104 lands, if that is the preferred order.

[carloscl03]

Another measurement that bears on this one, from the notebook CI on the fork.

Running the tutorial suite on the gdstk backend, GLayout_Cells raises in Component.add without this PR — the same TypeError: Component.add: unsupported type Component that this branch fixes. The notebook masks it: the failing cell assigns inside a widgets.Output() context, so what surfaces is a NameError on the next line and the real cause is swallowed.

This matters beyond the one cell. The notebooks job is why six of the eight open PRs are red right now: two notebooks sit on the 180s per-cell limit and cross it depending on the runner, so the check flips on identical content. Moving the job to gdstk takes the suite from 660s to 158s and off the limit — but it needs this PR, #104 and #113 together. Without this one, GLayout_Cells raises in Component.add.

Runs on this fork's CI, same container and runners: gdsfactory baseline · gdstk. Full table in #116.

The _gdstk.py conflict with #104 described in my previous comment still stands, and #104 has since gained one more commit in that file (add_ref taking columns/rows/spacing), which does not overlap the conflicting hunks.

[carloscl03]

Rebased onto current main (35 commits behind), so this now carries the tests.yml workflow from #112 and its unit tests run here.

Worth flagging what that surfaced. Against main the suite has 10 xfails; with this branch, three of them xpass:

XPASS  diff_pair_ibias-gdstk              (pre-existing: current_mirror_interdigitized_netlist() missing 'fingers' arg)
XPASS  low_voltage_cmirror_standalone-gdstk (pre-existing: KeyError on ref.info['netlist'])
XPASS  diff_pair_stackedcmirror-gdstk     (pre-existing: current_mirror_interdigitized_netlist() missing 'fingers' arg)

Those three cells were marked as known-broken; the port-renaming fix and the info delegation make them build. The remaining failures are identical to main's (all -gdsfactory variants, unrelated to this PR).

On merging alongside #104

There is no conflict with main — this merges clean. The only overlap is with #104, in ComponentReference in _gdstk.py, and it does not go away by rebasing since both PRs add to the same class. Details and the resolution are in my earlier comment above; the short version:

• __init__ — gdstk backend: close API gaps so the tutorials run #104 gives the reference its own self.info = {}; this PR makes info a property delegating to the parent. Keeping both compiles and then wipes the parent's metadata on every placement, netlist included. Keep the property, drop the assignment, keep gdstk backend: close API gaps so the tutorials run #104's self._name.
• __getitem__ (gdstk backend: close API gaps so the tutorials run #104) vs pprint_ports (this PR) — distinct methods, keep both.

Verified on the fork's CI with that resolution plus #100/#103/#113/#114: the tutorial suite runs 14/14 in 156s. Happy to push the resolved merge here the moment #104 lands, whichever order suits you.