Class method body not executed when class is imported from another module

[proggeramlug]

Summary

On Perry 0.5.93, when a class is defined in module A and its method is called on an instance obtained in module B, the method body never executes. Perry returns a stub value of the declared return type. Same-file class method calls work correctly.

This is the final blocker for @perry/postgres: every conn.query(...) call on the driver's Connection instance returns an empty QueryResult stub instead of actually running the query. The class is defined in src/connection.ts, re-exported from src/index.ts, imported by user scripts — that import boundary is enough to trigger this.

Repro

perry-classlib/
├── lib.ts
└── main.ts

lib.ts:

export class Thing {
    private readonly _id: number;
    constructor(id: number) { this._id = id; }

    doWork(s: string): Promise<string> {
        console.log('[Thing.doWork] entered id=' + this._id + ' s=' + s);
        return new Promise<string>((resolve) => {
            setTimeout(() => resolve('work-done-' + s), 10);
        });
    }
}

export function makeThing(): Promise<Thing> {
    return new Promise<Thing>((resolve) => {
        setTimeout(() => resolve(new Thing(42)), 10);
    });
}

main.ts:

import { makeThing } from './lib';

async function main(): Promise<void> {
    const t = await makeThing();
    console.log('typeof t=' + typeof t + ' typeof doWork=' + typeof t.doWork);
    const r = await t.doWork('hi');
    console.log('r=' + r);
}

main().then(() => console.log('[main] done'));

Observed on Perry 0.5.93

typeof t=object typeof doWork=undefined
r=[object Object]
[main] done

• [Thing.doWork] entered is never logged — the method body never ran.
• r is [object Object] — Perry returned a raw stub object instead of await-ing the Promise chain to a string.

Expected (Bun / Node output)

typeof t=object typeof doWork=function
[Thing.doWork] entered id=42 s=hi
r=work-done-hi
[main] done

Same-file case works fine

Moving Thing and makeThing into the same file as main() makes the method body execute correctly. The bug is specifically about the import boundary.

Likely connected to

• typeof obj.method returning 'undefined' even when the method is callable — probably the same method-lookup path misses on imported classes (unrelated but-also-broken symptom: on a same-file class, typeof obj.method returns 'undefined' but the call still works).
• await returns stub before setTimeout fires when resolved value is an object literal #77 (fixed) gave me a working path for Promises resolving object literals — that exposed this, because the stub return value from cross-module method calls is what the driver was getting as QueryResult (all fields undefined).

Impact

Every TS library that exports a class with methods and expects consumers to import it is currently non-functional on Perry. This includes @perry/postgres (blocks all queries).

Environment

• Perry 0.5.93
• macOS 26.4
• perry run main.ts

[proggeramlug]

Fixed in v0.5.94 (2ab4947).

Diagnosis: The await makeThing() binding came back as Any in the HIR (imported functions return Type::Any at the cross-module boundary), so receiver_class_name returned None and dispatch fell into the dynamic tower. The tower enumerates ctx.methods for implementors of the property name — but opts.imported_classes only carried explicitly-named specifiers, so Thing (imported implicitly via makeThing's return type) wasn't registered. No implementors → fell through to js_native_call_method → returned the raw ObjectHeader as a stub. Hence r=[object Object] with the method body never entering.

Fix (perry/src/commands/compile.rs): for each named import from a native-compiled module, walk ctx.native_modules directly and register every class.is_exported class from each module in the transitive origin set (resolved_path + everything all_module_exports[resolved_path] re-exports). The important detail: iterating exported_classes instead would have been wrong — its re-export propagation loop at lines 4110-4173 stamps alias entries under every re-exporter's path (so Pool would be keyed by both pool.ts AND index.ts), and the alias entry hands us a src_path that produces the wrong mangled perry_method_<prefix>__<Class>__<method> symbol. Iterating ctx.native_modules.classes directly guarantees src_path is the class's true defining module. First test I did had exactly this bug — @perry/postgres's cold-start-minimal.ts failed to link with Undefined symbols: _perry_method_src_index_ts__Pool__query because Pool was compiled under src_pool_ts.

Dedup by class name in the live vec so multi-import duplicates don't stack duplicate @perry_class_keys_<modprefix>__<Class> globals in IR. Same-name local classes still win via the existing class_table.contains_key check in compile_module.

Verified: your repro now prints [Thing.doWork] entered id=42 s=hi and r=work-done-hi. Cross-module inheritance (Derived extends Base) with dynamic dispatch also works. Most importantly: @perry/postgres's examples/cold-start-minimal.ts now compiles and runs end-to-end against a real Postgres 16 — combined with v0.5.92 (#75, process.exit) and v0.5.93 (#77, async-return Promise unwrap), the full connect → query('SELECT 1') → process.exit(0) flow completes cleanly with exit code 0 (previously it hung or returned garbage). 108 runtime + 38 perry CLI + 38 codegen/hir tests pass; gap suite unchanged.

Side-note on typeof obj.method === 'undefined': pre-existing Perry quirk (affects same-file classes too) — methods aren't stored as object fields, they're looked up through the ctx.methods registry at call sites. Reading obj.method as a property-get goes through the generic PropertyGet path which doesn't consult that registry, so it returns undefined. The call still works because t.method(args) at the call site sees the PropertyGet-then-call pattern and routes through method dispatch, not the value of .method. That's a separate cleanup — not part of #83's scope.

[proggeramlug]

Closed by 2ab4947 (v0.5.94).