Whole-program inference is require-path/layout sensitive — library consumption needs a stable package identity

[OriPekelman]

Symptom

When a downstream Spinel program requires a library's source via a different relative path than the path the library uses in its own build, whole-program type inference fragments the type table differently. Concretely, an Array<Mat>-shaped declaration compiled clean but generated a C-codegen reference to an undefined sp_Mat type (sp_Mat undeclared) in the consumer, where Mat is a user class defined in the library.

Documented downstream in OriPekelman/toy (docs/consuming-toy.md, toy#19): hand-pathing require_relative "../toy/lib/.../transformer" (where Mat lives) into a consumer fragments inference vs. toy's own build.

Current workaround

Vendor the library's entire source tree in the exact layout the library compiles with (the spinelgems bundler-spinel convention). Same tree shape → inference stays monomorphic the way the library's own build expects. This works but makes library composition fragile off that golden path, and is a large part of why the vendoring convention has to exist.

Ask

A stable package / namespace identity so a user class (e.g. Mat) resolves to the same monomorphic C type regardless of the require path it's reached through — so a downstream program can compose a library's primitives without reproducing the library's exact directory layout.

Related

• The name-keyed cross-module inference family (Struct.new accessor names act as global type-merge keys → unrelated code mis-typed (member b unifies with an unrelated #b) #1043 — Struct accessors / param names widening unrelated methods). Same "inference keyed on something non-semantic" shape, different axis (require path / layout here).
• Downstream toy added a gate-poly-degrade CI gate that fails on new cannot resolve … on poly … (emitting 0) warnings — it guards regressions of this class but not the root layout-sensitivity.

A minimal self-contained repro (one file required via two paths → divergent inference) is a TODO; filing now to capture the design need since it's the root of the downstream vendoring brittleness.

[matz]

Checking in on this one since it's been open a while.

On current master a few things have moved that touch the class-identity axis here:

• Same-base-name classes in different modules collide to one sp_<Name> (module dropped from mangling) → struct/method merge, uninitialized ivar, SIGSEGV (regression vs legacy) #1425 (qualify_colliding_classes) gave same-leaf-name classes in different modules distinct, module-qualified C identities (sp_Web__Response vs sp_Chat__Response) instead of collapsing onto one sp_<Leaf>. That's the name-collision half of "a user class resolves to the same C type" — orthogonal to the require-path axis here, but related (Struct.new accessor names act as global type-merge keys → unrelated code mis-typed (member b unifies with an unrelated #b) #1043 is the other relative).

I tried to reproduce the layout/require-path half — a library class Mat consumed through a different relative require_relative than the library's own build, plus Array<Mat>-shaped usage in the consumer — across a few shapes (Mat instantiated in the consumer; Mat reached only through a typed ivar/array; consumer requiring ../lib/transformer vs the lib's own require_relative "mat"). All compile clean on current master and run correctly — sp_Mat emits (typedef + initialize + struct) and resolves, no sp_Mat undeclared. So I can't yet provoke the divergence standalone.

The concrete codegen symptom you saw — sp_Mat undeclared: a class referenced as a type (an array element / ivar slot) whose struct is pruned from emission while a sp_Mat * reference survives — would be an independently fixable reachability bug (ensure a class used purely as a type still gets its struct emitted), separate from the broader package-identity design ask. If you can share the minimal one-file-required-via-two-paths → divergent inference reduction you noted as a TODO (even a reduced toy-derived consumer that still prints sp_Mat undeclared), I can bisect the fragmenting site and tackle that concrete half now, while the stable-package-identity design discussion continues. Thanks!