fix(runtime): a subclass override of a native base method must win over the native surface (#6316)

[proggeramlug]

Fixes #6316.

Root cause — there are TWO, and they are independent

The issue asked whether the dispatch bypass and the super.<m>() failure are one
root cause or two. Two. They happen to coincide on EventEmitter, which is
why the repro looks like a single bug.

1. The override bypass — a native base's methods are OWN PROPERTIES

perry models EventEmitter and every node:stream class by stamping the base's
method surface directly onto the instance: js_event_emitter_subclass_init /
js_node_stream_*_subclass_init call install_methods_on_existing_object, which
does js_object_set_field_by_name(obj, "emit", <native closure>). Nothing lives
on a prototype.

Own properties legitimately shadow class methods, and perry implements that
faithfully: the #620 own-property-override probe
(perry-codegen/src/lower_call/method_override.rs) emits a runtime
js_object_get_own_field_or_undef(recv, "emit") before every static class-method
dispatch, and takes the own-property branch when it hits.

So for class Bus extends EventEmitter { emit() {…} }, the probe found the
native base's emit sitting on the instance and called it in preference to
Bus.prototype.emit. Inheritance ran backwards. The mechanism designed to
honour this.method = fn was being fed the base class's own prototype surface.

The override never ran, with no error and no warning — a wrong answer rather than
a crash, the worst failure mode.

2. super.<m>() into a native base was independently dead

js_super_method_call_dynamic resolves from
get_parent_class_id(child_class_id). A native base is not a perry class —
EventEmitter owns no class id and no CLASS_REGISTRY entry — so a
class Bus extends EventEmitter has no parent edge at all. The helper fell
straight off its parent_cid == 0 guard and returned undefined.

This one is not specific to EventEmitter: it is why super.push() on an
Array subclass silently no-ops and super.toString() on an Error subclass
yields undefined (see the matrix below).

The fix

Install a base method under its plain name only when the receiver's class chain
does not declare it (method_owner_class_id — the class registry is populated
at module init, long before any new). When the subclass does override it, the
native closure is stashed under the reserved __perry_native_super__<name> key
instead:

• invisible to ordinary property lookup, so the user's class method wins — the
  own-property probe now misses, exactly as it should;
• still reachable from js_super_method_call_dynamic, so super.emit(…) lands
  on the real base implementation. The fallback runs last, after the vtable
  and prototype-registry lookups, so a genuine user-class parent method always
  wins — the same "native is the fallback, the class chain wins" ordering
  discipline PR fix(runtime): EventTarget methods must live on the prototype so subclasses inherit them (#6301) #6311 established for EventTarget.

addListener keeps aliasing the base on even when the subclass overrides on,
matching Node (EventEmitter.prototype.addListener === EventEmitter.prototype.on
refers to the base function).

The reserved key is hidden from Object.keys / for…in / JSON.stringify via
is_internal_runtime_key_bytes. That is a strict move toward Node: the
displaced method previously sat on the instance under its plain name, so
Object.keys(bus) wrongly reported emit as an own key.

install_methods_on_existing_object also now roots the receiver and the NaN-boxed
this in a RuntimeHandleScope — key interning and js_closure_alloc both
allocate and can GC-move the receiver, and the loop stores through it repeatedly.

Affected-base matrix

Measured on a clean build of the base commit, each case = override + super call,
diffed against node --experimental-strip-types.

native base	override runs?	super.<m>() reaches base?	status
EventEmitter	NO — bypassed	NO	fixed here (both causes)
node:stream (Readable, Writable, …)	NO — bypassed	NO	fixed here (same mechanism)
EventTarget	n/a — subclass inherits nothing	n/a	#6301 / PR #6311
Array	yes	NO — super.push() no-ops	cause 2, unfixed
Error	yes	NO — super.toString() → undefined	cause 2, unfixed
Promise	yes	NO — super.then not a function	cause 2, unfixed
Map / Set	yes	NO	subclassing itself is broken — see below

Only EventEmitter and the stream classes stamp their surface onto the instance,
so cause 1 is exactly those. Cause 2 spans every native base.

Two adjacent pre-existing bugs surfaced while measuring; both are unchanged by
this PR (verified byte-identical to the base build) and both deserve their own
issues rather than being folded in here:

• class X extends Map / extends Set is broken with no override at all —
  class M extends Map {}; new M().set("a", 1) already throws
  TypeError: set is not a function on main. Their super failures in the table
  are a symptom of that, not of override ordering.
• An INDIRECT native base never runs the subclass init —
  class D extends B, class B extends EventEmitter inherits nothing, override
  or not, because the init only fires when extends_name is literally
  EventEmitter. This is the EventEmitter mirror of the chain-walk fix(runtime): EventTarget methods must live on the prototype so subclasses inherit them (#6301) #6311 added
  for EventTarget. The fixture documents the exclusion explicitly.

Before / after

import { EventEmitter } from "node:events";
class Bus extends EventEmitter {
  emit(ev: string, ...args: any[]): boolean {
    console.log("override ran:", ev);
    return super.emit(ev, ...args);
  }
}
const b = new Bus();
b.on("ping", (x: number) => console.log("listener got:", x));
console.log("emit returned:", b.emit("ping", 42));

before                     after (== node)
──────────────────         ──────────────────────
listener got: 42           override ran: ping
emit returned: true        listener got: 42
                           emit returned: true

Testing

• test-files/test_gap_6316_native_base_override.ts — byte-identical to
  node --experimental-strip-types. Covers: the issue's repro; several overrides
  at once (on + emit) each forwarding to the base; a non-overridden base
  method on an overriding subclass still reaching the base; a no-override
  control; an explicit constructor + instance state; own-key hygiene; and
  Readable.push / Writable.write overrides + super.
• Full gap suite A/B, 287 tests, zero regressions. Run twice with the same
  compiler, swapping only the runtime .a (baseline vs fixed) so the comparison
  isolates this change. Three tests differed: this PR's new fixture, plus
  test_gap_console_methods and test_gap_module_const_local_shadow — both
  proven flaky on the baseline binary alone (console.time wall-clock values;
  a pre-existing uninitialized-denormal print that varies every run).
• cargo test -p perry-runtime — 1264 passed, 0 failed.
• cargo fmt --all -- --check, file-size gate, GC store-site inventory, and the
  addr-class audit all pass.

Relationship to PR #6311

Independent — no file overlap, and this branch is based on origin/main, not on
#6311's branch. #6311 gives EventTarget a method surface it never had and places
it last so an override wins; this PR removes a surface that was wrongly placed
first. They implement the same ordering rule (the user's class chain wins,
native is the fallback) from opposite directions and should merge cleanly in
either order.

[coderabbitai]

Warning

Review limit reached

@proggeramlug, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 40 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 2d065a38-1b3f-446b-9714-e9f12f68fbb8

📥 Commits

Reviewing files that changed from the base of the PR and between 2c32585 and f53e538.

📒 Files selected for processing (4)

• crates/perry-runtime/src/node_stream_dispatch.rs
• crates/perry-runtime/src/object/class_constructors.rs
• crates/perry-runtime/src/object/field_get_set/enumeration.rs
• test-files/test_gap_6316_native_base_override.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/6316-native-base-override-bypass

---

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.}