fix(compile): a namespace member named like a global must not shadow it

[proggeramlug]

Fixes #10945.

Symptom

The OpenCode v1.18.30 link fails on an undefined wrapper for effect's Array export:

undefined reference to `__perry_wrap_perry_fn_…effect_src_Array_ts__Array_$info'

The references come from closures in effect's Chunk.ts, Cron.ts and internal/effect.ts. The same bug gives wrong answers in programs that do link. Two modules:

// a.ts
export const Array = globalThis.Array
export function f(x: number) { return x + 1 }

// main.ts
import * as A from "./a.ts"
function inner(n: number) { return new Array(n).fill(0).length }
console.log(inner(3))      // node: 3   perry on main: undefined

With import { f } in place of the namespace import, or with no import at all, perry prints 3.

Cause

Not the auto-optimize pass the issue suspected: the link failed identically in a build where that pass never ran. And not a missing definition: Array.ts's own object defines the wrapper and its info record as …__Array / …__Array$info, while the failing importers ask for …__Array_$info.

A namespace import registers every member of the imported module in the flat import_function_prefixes map, as a best-effort fallback for bare-name calls (#5927). The code's own comments say genuine namespace-member accesses are resolved authoritatively through the per-namespace namespace_member_prefixes map. effect's Array.ts exports const Array = globalThis.Array, so the flat map gains an entry for Array. lower_new (from #10589) treats any name in that map as a user-owned constructor:

let user_owns_construction = ctx.import_function_prefixes.contains_key(class_name) && …;
if !ctx.classes.contains_key(class_name) && !user_owns_construction { /* builtin `new` */ }

So the importer's own bare new Array(n) constructs the member instead of the builtin. effect's Chunk.ts, Cron.ts and internal/effect.ts all do import * as … from "./Array.ts" and write new Array(n). That path names the wrapper under a symbol the owning module never emits, and the link fails.

This is the class #10356 fixed for classes — an implicitly registered export shadowing a global intrinsic — reached here through the namespace-import fallback for functions and values.

Fix

In both namespace fallback loops — import * as X and a namespace re-export (export * as X) — skip the flat, bare-name entries for names is_global_intrinsic_value_name recognises, exactly as #10356 does for classes. Five insertions per loop are gated: import_function_prefixes, import_function_origin_names, and the bare-key entries of imported_param_counts, imported_has_rest and imported_synthetic_arguments. The per-namespace entries (namespace_member_prefixes, namespace_member_origin_names, the scoped-key metadata) are untouched, so A.Array and every other member still resolve. An explicit named import goes through the specifier-driven path and is unaffected. A bare Array in a module that never imported a bare Array can only mean the global.

Test

crates/perry/tests/issue_10945_namespace_member_shadows_global.rs compiles a four-module program end to end and compares its output byte for byte with node 26.5.1's:

• bare new Array(n) inside a function, Array.isArray, Array.from, and Array.of inside a closure — the importer's globals;
• Arr.Array === globalThis.Array, new Arr.Array(2) and Arr.bump(41) — namespace members must keep resolving;
• import { Map } from "./fake_map.js" — Importing one name from a module also binds that module's OTHER exported classes — a user class Request shadows the global Request in the importer (OpenCode TUI bootstrap wall) #10356's control: an explicit named import of a global-shadowing class must still win.

Both arms were run as real commits, with the runtime libraries rebuilt from each, so a failure can only be the program's output and never a build-stamp mismatch:

• with the fix: passes;
• with run_pipeline.rs reverted: fails at the output assertion with 1 new Array(n): undefined. Lines 2–8 are identical in both arms, so the controls were never affected.

cargo fmt --all -- --check is clean. With this and #11817 / #11819, the OpenCode v1.18.30 build gets through codegen and past this symbol at link; a full build with all three is running and I will post its result.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

Note

Currently processing new changes in this PR. This may take a few minutes, please wait...

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 123bf58a-c263-4461-a558-08fb96df6bde

📥 Commits

Reviewing files that changed from the base of the PR and between 72eafb8 and 25867e0.

📒 Files selected for processing (2)

• crates/perry/src/commands/compile/run_pipeline.rs
• crates/perry/tests/issue_10945_namespace_member_shadows_global.rs

 ______________________________
< torvalds@linux:~$ git review >
 ------------------------------
  \
   \   \
        \ /\
        ( )
      .( o ).

✨ Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[proggeramlug]

With this PR plus #11817 and #11819 on main 681d7024, the full OpenCode v1.18.30 build now compiles and links natively on Linux x86_64: perry compile exits 0 after 68 minutes and produces a 1.08 GB binary, with auto-optimize on (runtime, stdlib and ext-http rebuilt for the program's feature set).

Compared with the official bun build of the same checkout (packages/opencode/script/build.ts --single):

	bun	perry
--version	rc 0	rc 0
--help	rc 0, 4285 B	rc 0, 4285 B
models	rc 0, 850 B	rc 0, 815 B — one entry missing
TUI (pty)	rc 124, 75 truecolor cells	rc 134 — a static-ShapeId abort at startup
--version startup	444 ms	2700 ms

The TUI abort is the static ShapeId 0x80015cb7 (proto 0x0) was refused by the shape mint, which is unrelated to these three fixes. I am root-causing it and will file it separately. opencode run still reports "Session not found", which is #10531.