getPrototype exception checks
#24985
Conversation
WalkthroughgetPrototype was changed to return an error-wrapped value (JSError!JSValue) and call sites were updated to use try/unwrap. Bindings and native exports were adjusted to surface exceptions, and prototype-access call sites and tests were updated to propagate or check for exceptions. Changes
Possibly related PRs
Suggested reviewers
Pre-merge checks✅ Passed checks (4 passed)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Disabled knowledge base sources:
📒 Files selected for processing (1)
🧰 Additional context used📓 Path-based instructions (3)src/**/*.{cpp,zig}📄 CodeRabbit inference engine (.cursor/rules/building-bun.mdc)
Files:
src/bun.js/bindings/**/*.cpp📄 CodeRabbit inference engine (CLAUDE.md)
Files:
src/**/*.{ts,zig,cpp}📄 CodeRabbit inference engine (CLAUDE.md)
Files:
🧠 Learnings (21)📓 Common learnings📚 Learning: 2025-11-24T18:36:33.049ZApplied to files:
📚 Learning: 2025-11-24T18:36:59.675ZApplied to files:
📚 Learning: 2025-11-24T18:36:33.049ZApplied to files:
📚 Learning: 2025-11-24T18:35:25.866ZApplied to files:
📚 Learning: 2025-11-24T18:37:47.887ZApplied to files:
📚 Learning: 2025-11-24T18:35:25.866ZApplied to files:
📚 Learning: 2025-11-24T18:35:25.866ZApplied to files:
📚 Learning: 2025-11-24T18:36:59.675ZApplied to files:
📚 Learning: 2025-11-24T18:35:39.196ZApplied to files:
📚 Learning: 2025-11-24T18:36:59.675ZApplied to files:
📚 Learning: 2025-11-24T18:35:25.866ZApplied to files:
📚 Learning: 2025-11-24T18:35:25.866ZApplied to files:
📚 Learning: 2025-11-24T18:36:08.548ZApplied to files:
📚 Learning: 2025-11-24T18:35:25.866ZApplied to files:
📚 Learning: 2025-11-24T18:36:08.548ZApplied to files:
📚 Learning: 2025-10-18T20:50:47.750ZApplied to files:
📚 Learning: 2025-11-24T18:35:25.866ZApplied to files:
📚 Learning: 2025-11-24T18:35:25.866ZApplied to files:
📚 Learning: 2025-11-24T18:35:25.866ZApplied to files:
📚 Learning: 2025-11-24T18:35:25.866ZApplied to files:
🔇 Additional comments (2)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (9)
src/bun.js/ConsoleObject.zig(3 hunks)src/bun.js/bindings/JSValue.zig(1 hunks)src/bun.js/bindings/bindings.cpp(4 hunks)src/bun.js/bindings/headers.h(0 hunks)src/bun.js/bindings/napi.cpp(1 hunks)src/bun.js/modules/NodeUtilTypesModule.cpp(1 hunks)src/bun.js/test/ScopeFunctions.zig(1 hunks)src/bun.js/test/pretty_format.zig(1 hunks)test/js/bun/util/inspect.test.js(1 hunks)
💤 Files with no reviewable changes (1)
- src/bun.js/bindings/headers.h
🧰 Additional context used
🧠 Learnings (20)
📓 Common learnings
Learnt from: pfgithub
Repo: oven-sh/bun PR: 24273
File: src/bun.js/bindings/JSValue.zig:545-586
Timestamp: 2025-11-03T20:40:59.655Z
Learning: In Bun's Zig codebase, JSErrors (returned as `bun.JSError!T`) must always be properly handled. Using `catch continue` or `catch { break; }` to silently suppress JSErrors is a bug. Errors should either be explicitly handled or propagated with `try`. This applies to snapshot serializer error handling where Jest's behavior is to throw when serializers throw.
📚 Learning: 2025-10-20T01:38:02.660Z
Learnt from: theshadow27
Repo: oven-sh/bun PR: 23798
File: packages/bun-otel/BunFetchInstrumentation.ts:126-131
Timestamp: 2025-10-20T01:38:02.660Z
Learning: In BunFetchInstrumentation.ts, the force-restore to ORIGINAL_FETCH in the disable() method is intentionally kept (despite appearing unsafe) because it's required for proper test cleanup when instrumentation is repeatedly enabled/disabled. Without it, 15 distributed tracing and context propagation tests fail. Shimmer's unwrap() doesn't reliably restore the original fetch in Bun's globalThis context. The isBunOtelPatched safety check ensures the restore only happens when the current fetch is still ours, preventing clobbering of other tools' wrappers.
Applied to files:
test/js/bun/util/inspect.test.js
📚 Learning: 2025-10-08T13:48:02.430Z
Learnt from: Jarred-Sumner
Repo: oven-sh/bun PR: 23373
File: test/js/bun/tarball/extract.test.ts:107-111
Timestamp: 2025-10-08T13:48:02.430Z
Learning: In Bun's test runner, use `expect(async () => { await ... }).toThrow()` to assert async rejections. Unlike Jest/Vitest, Bun does not require `await expect(...).rejects.toThrow()` - the async function wrapper with `.toThrow()` is the correct pattern for async error assertions in Bun tests.
Applied to files:
test/js/bun/util/inspect.test.js
📚 Learning: 2025-11-03T20:40:59.655Z
Learnt from: pfgithub
Repo: oven-sh/bun PR: 24273
File: src/bun.js/bindings/JSValue.zig:545-586
Timestamp: 2025-11-03T20:40:59.655Z
Learning: In Bun's Zig codebase, JSErrors (returned as `bun.JSError!T`) must always be properly handled. Using `catch continue` or `catch { break; }` to silently suppress JSErrors is a bug. Errors should either be explicitly handled or propagated with `try`. This applies to snapshot serializer error handling where Jest's behavior is to throw when serializers throw.
Applied to files:
test/js/bun/util/inspect.test.jssrc/bun.js/modules/NodeUtilTypesModule.cppsrc/bun.js/test/pretty_format.zigsrc/bun.js/bindings/bindings.cppsrc/bun.js/ConsoleObject.zigsrc/bun.js/bindings/napi.cpp
📚 Learning: 2025-11-06T00:58:23.965Z
Learnt from: markovejnovic
Repo: oven-sh/bun PR: 24417
File: test/js/bun/spawn/spawn.test.ts:903-918
Timestamp: 2025-11-06T00:58:23.965Z
Learning: In Bun test files, `await using` with spawn() is appropriate for long-running processes that need guaranteed cleanup on scope exit or when explicitly testing disposal behavior. For short-lived processes that exit naturally (e.g., console.log scripts), the pattern `const proc = spawn(...); await proc.exited;` is standard and more common, as evidenced by 24 instances vs 4 `await using` instances in test/js/bun/spawn/spawn.test.ts.
Applied to files:
test/js/bun/util/inspect.test.js
📚 Learning: 2025-11-08T04:06:33.198Z
Learnt from: Jarred-Sumner
Repo: oven-sh/bun PR: 24491
File: test/js/bun/transpiler/declare-global.test.ts:17-17
Timestamp: 2025-11-08T04:06:33.198Z
Learning: In Bun test files, `await using` with Bun.spawn() is the preferred pattern for spawned processes regardless of whether they are short-lived or long-running. Do not suggest replacing `await using proc = Bun.spawn(...)` with `const proc = Bun.spawn(...); await proc.exited;`.
Applied to files:
test/js/bun/util/inspect.test.js
📚 Learning: 2025-09-20T03:39:41.770Z
Learnt from: pfgithub
Repo: oven-sh/bun PR: 22534
File: test/regression/issue/21830.fixture.ts:14-63
Timestamp: 2025-09-20T03:39:41.770Z
Learning: Bun's test runner supports async describe callbacks, unlike Jest/Vitest where describe callbacks must be synchronous. The syntax `describe("name", async () => { ... })` is valid in Bun.
Applied to files:
test/js/bun/util/inspect.test.js
📚 Learning: 2025-09-20T00:58:38.042Z
Learnt from: markovejnovic
Repo: oven-sh/bun PR: 22568
File: test/js/valkey/valkey.test.ts:561-564
Timestamp: 2025-09-20T00:58:38.042Z
Learning: For test/js/valkey/valkey.test.ts, do not comment on synchronous throw assertions for async Redis methods (like ctx.redis.set(), ctx.redis.unsubscribe(), etc.) - Bun's Redis client implementation differs from Node.js and can throw synchronously even for async methods. The maintainer has explicitly requested to stop looking at this error pattern.
Applied to files:
test/js/bun/util/inspect.test.js
📚 Learning: 2025-09-30T22:53:19.887Z
Learnt from: pfgithub
Repo: oven-sh/bun PR: 23117
File: src/bun.js/test/snapshot.zig:265-276
Timestamp: 2025-09-30T22:53:19.887Z
Learning: In Bun's snapshot testing (src/bun.js/test/snapshot.zig), multiple inline snapshots at the same line and column (same call position) must have identical values. However, multiple inline snapshots on the same line at different columns are allowed to have different values. The check is position-specific (line+col), not line-wide.
Applied to files:
test/js/bun/util/inspect.test.js
📚 Learning: 2025-10-25T17:20:19.041Z
Learnt from: theshadow27
Repo: oven-sh/bun PR: 24063
File: test/js/bun/telemetry/server-header-injection.test.ts:5-20
Timestamp: 2025-10-25T17:20:19.041Z
Learning: In the Bun telemetry codebase, tests are organized into two distinct layers: (1) Internal API tests in test/js/bun/telemetry/ use numeric InstrumentKind enum values to test Zig↔JS injection points and low-level integration; (2) Public API tests in packages/bun-otel/test/ use string InstrumentKind values ("http", "fetch", etc.) to test the public-facing BunSDK and instrumentation APIs. This separation allows internal tests to use efficient numeric enums for refactoring flexibility while the public API maintains a developer-friendly string-based interface.
Applied to files:
test/js/bun/util/inspect.test.js
📚 Learning: 2025-10-18T23:43:42.502Z
Learnt from: Jarred-Sumner
Repo: oven-sh/bun PR: 23817
File: src/js/node/test.ts:282-282
Timestamp: 2025-10-18T23:43:42.502Z
Learning: In the Bun repository, the error code generation script (generate-node-errors.ts) always runs during the build process. When reviewing code that uses error code intrinsics like $ERR_TEST_FAILURE, $ERR_INVALID_ARG_TYPE, etc., do not ask to verify whether the generation script has been run or will run, as it is automatically executed.
Applied to files:
src/bun.js/modules/NodeUtilTypesModule.cpp
📚 Learning: 2025-10-01T21:59:54.571Z
Learnt from: taylordotfish
Repo: oven-sh/bun PR: 23169
File: src/bun.js/bindings/webcore/JSDOMConvertEnumeration.h:47-74
Timestamp: 2025-10-01T21:59:54.571Z
Learning: In the new bindings generator (bindgenv2) for `src/bun.js/bindings/webcore/JSDOMConvertEnumeration.h`, the context-aware enumeration conversion overloads intentionally use stricter validation (requiring `value.isString()` without ToString coercion), diverging from Web IDL semantics. This is a design decision documented in comments.
Applied to files:
src/bun.js/modules/NodeUtilTypesModule.cppsrc/bun.js/test/ScopeFunctions.zigsrc/bun.js/bindings/bindings.cppsrc/bun.js/ConsoleObject.zigsrc/bun.js/bindings/JSValue.zigsrc/bun.js/bindings/napi.cpp
📚 Learning: 2025-10-01T21:49:27.862Z
Learnt from: taylordotfish
Repo: oven-sh/bun PR: 23169
File: src/bun.js/bindings/BunIDLConvert.h:29-42
Timestamp: 2025-10-01T21:49:27.862Z
Learning: In Bun's IDL bindings (src/bun.js/bindings/BunIDLConvert.h), IDLStrictNull intentionally treats both undefined and null as null (using isUndefinedOrNull()), matching WebKit's IDLNull & IDLNullable behavior. This is the correct implementation and should not be changed to only accept null.
Applied to files:
src/bun.js/modules/NodeUtilTypesModule.cppsrc/bun.js/ConsoleObject.zig
📚 Learning: 2025-10-17T01:21:35.060Z
Learnt from: taylordotfish
Repo: oven-sh/bun PR: 23755
File: src/bun.js/bindings/BunIDLConvert.h:79-95
Timestamp: 2025-10-17T01:21:35.060Z
Learning: In JavaScriptCore (used by Bun), the `toBoolean()` method implements ECMAScript's ToBoolean abstract operation, which is side-effect-free and cannot throw exceptions. It does not execute arbitrary JavaScript or invoke user-defined methods like Symbol.toPrimitive. Exception handling is not needed after toBoolean() calls.
Applied to files:
src/bun.js/modules/NodeUtilTypesModule.cpp
📚 Learning: 2025-10-11T15:19:30.301Z
Learnt from: mastermakrela
Repo: oven-sh/bun PR: 19167
File: src/bun.js/api.zig:31-31
Timestamp: 2025-10-11T15:19:30.301Z
Learning: The learnings about `pub const js = JSC.Codegen.JS<ClassName>` and re-exporting toJS/fromJS/fromJSDirect apply to class-based Zig bindings with constructors and prototype methods (e.g., those with `new` constructors). They do NOT apply to simple namespace-style API objects like TOMLObject, YAMLObject, and CSVObject which expose static functions via a `create()` method that returns a plain JS object.
Applied to files:
src/bun.js/test/ScopeFunctions.zigsrc/bun.js/bindings/bindings.cppsrc/bun.js/ConsoleObject.zigsrc/bun.js/bindings/JSValue.zig
📚 Learning: 2025-11-03T20:43:06.996Z
Learnt from: pfgithub
Repo: oven-sh/bun PR: 24273
File: src/bun.js/test/snapshot.zig:19-19
Timestamp: 2025-11-03T20:43:06.996Z
Learning: In Bun's Zig codebase, when storing JSValue objects in collections like ArrayList, use `jsc.Strong.Optional` (not raw JSValue). When adding values, wrap them with `jsc.Strong.Optional.create(value, globalThis)`. In cleanup code, iterate the collection calling `.deinit()` on each Strong.Optional item before calling `.deinit()` on the ArrayList itself. This pattern automatically handles GC protection. See examples in src/bun.js/test/ScopeFunctions.zig and src/bun.js/node/node_cluster_binding.zig.
Applied to files:
src/bun.js/test/ScopeFunctions.zigsrc/bun.js/bindings/bindings.cppsrc/bun.js/bindings/JSValue.zig
📚 Learning: 2025-10-18T20:50:47.750Z
Learnt from: theshadow27
Repo: oven-sh/bun PR: 23798
File: src/bun.js/telemetry.zig:366-373
Timestamp: 2025-10-18T20:50:47.750Z
Learning: In Bun's Zig codebase (src/bun.js/bindings/JSValue.zig), the JSValue enum uses `.null` (not `.js_null`) for JavaScript's null value. Only `js_undefined` has the `js_` prefix to avoid collision with Zig's built-in `undefined` keyword. The correct enum fields are: `js_undefined`, `null`, `true`, `false`, and `zero`.
Applied to files:
src/bun.js/test/ScopeFunctions.zigsrc/bun.js/bindings/bindings.cppsrc/bun.js/ConsoleObject.zigsrc/bun.js/bindings/JSValue.zig
📚 Learning: 2025-09-19T19:55:22.427Z
Learnt from: markovejnovic
Repo: oven-sh/bun PR: 22568
File: src/valkey/js_valkey_functions.zig:853-854
Timestamp: 2025-09-19T19:55:22.427Z
Learning: In Bun's JSPromise API, `resolvedPromiseValue(globalThis: *JSGlobalObject, value: JSValue) JSValue` returns a JSValue directly (not a JSPromise that needs `.toJS()` called on it). This is different from `resolvedPromise()` which returns a *JSPromise that would need `.toJS()`.
Applied to files:
src/bun.js/test/ScopeFunctions.zigsrc/bun.js/bindings/JSValue.zig
📚 Learning: 2025-09-05T19:49:26.188Z
Learnt from: markovejnovic
Repo: oven-sh/bun PR: 21728
File: src/valkey/js_valkey_functions.zig:852-867
Timestamp: 2025-09-05T19:49:26.188Z
Learning: In Bun’s Zig code, `.js_undefined` is a valid and preferred JSValue literal for “undefined” (e.g., resolving JSPromise). Do not refactor usages to `jsc.JSValue.jsUndefined()`, especially in src/valkey/js_valkey_functions.zig unsubscribe().
Applied to files:
src/bun.js/test/ScopeFunctions.zigsrc/bun.js/bindings/bindings.cppsrc/bun.js/bindings/JSValue.zig
📚 Learning: 2025-09-05T19:49:26.188Z
Learnt from: markovejnovic
Repo: oven-sh/bun PR: 21728
File: src/valkey/js_valkey_functions.zig:852-867
Timestamp: 2025-09-05T19:49:26.188Z
Learning: In Bun's Zig codebase, `.js_undefined` is a valid way to represent JavaScript's undefined value when working with JSPromise.resolve() and similar JavaScript interop functions. This is the correct pattern to use rather than `jsc.JSValue.jsUndefined()`.
Applied to files:
src/bun.js/bindings/JSValue.zig
🪛 Biome (2.1.2)
test/js/bun/util/inspect.test.js
[error] 98-100: This getter should return a value.
(lint/suspicious/useGetterReturn)
🔇 Additional comments (10)
src/bun.js/bindings/JSValue.zig (1)
1278-1279: getPrototype wrapper correctly exposes an error-aware APIThe new
getPrototypesignature and implementation are consistent with otherbun.cppbindings that useJSError!T, ensuring prototype access failures propagate instead of leaking.zerosentinels into callers.src/bun.js/ConsoleObject.zig (3)
2035-2043: getObjectName now correctly propagates prototype lookup errorsSwitching to
try value.getPrototype(globalThis)ensures exceptions fromObject.getPrototypeOf/proxy traps surface asbun.JSErrorinstead of being silently ignored, while still treating a.nullprototype as[Object: null prototype]. This matches the project’s convention of not suppressingJSError!Tresults. Based on learnings, this is the desired behavior.
2317-2339: Class formatter safely handles exceptions when reading the prototypeUsing
const proto = try value.getPrototype(this.globalThis);means any error in the class’s prototype chain aborts formatting viaJSErrorinstead of flowing a bogus.zerointogetClassName, which previously could crash. The rest of the.Classformatting logic is unchanged for successful lookups.
2344-2346: Function formatter now treats prototype failures as real errorsFetching the function’s prototype with
try value.getPrototype(this.globalThis)before callingproto.getNamecorrectly turns prototype-chain failures intoJSErrorrather than undefined behavior on.zero/non-cell values. This keeps the “Function/AsyncFunction/GeneratorFunction” labeling behavior intact when prototype retrieval succeeds.src/bun.js/bindings/bindings.cpp (2)
3694-3698: Confirm zero_is_throw contract forJSC__JSValue__getPrototype.Annotating this binding with
[[ZIG_EXPORT(zero_is_throw)]]matches the goal of makinggetPrototypeerror-propagating into Zig, assumingJSValue::getPrototypereturns an empty JSValue on exception (which encodes to 0). The implementation itself is otherwise unchanged and looks fine.Please just double-check that:
- The Zig side now treats this as
JSError!JSValue(or equivalent) and usestryrather than ignoring errors.- There are no remaining call sites that still assume this binding can never throw.
This keeps the new error semantics consistent with other JSError-based bindings.
4967-4974: Exception checks aroundgetPrototypeinforEachPropertyImpllook correct.Adding
RETURN_IF_EXCEPTION(scope, void());after bothobject->getPrototype(globalObject)anditerating->getPrototype(globalObject)ensures proxy[[GetPrototypeOf]]traps (and other prototype lookups) can’t leave a pending exception during property traversal. Semantics for normalnull/object prototypes remain unchanged.This aligns with the rest of the function’s exception handling and should address the fuzzed
Bun.inspectcrash path without introducing new behavior changes.Also applies to: 5168-5170
src/bun.js/modules/NodeUtilTypesModule.cpp (1)
120-145: Safely propagating exceptions fromgetPrototypeinjsFunctionIsErrorAdding
RETURN_IF_EXCEPTION(scope, {});afterobject->getPrototype(globalObject)correctly treats prototype lookup as potentially throwing and bails out via the existing throw scope instead of risking an unhandled VM exception. This is consistent with the updated error‑awaregetPrototypesemantics.src/bun.js/bindings/napi.cpp (1)
1820-1841: Correctly mapping prototype access exceptions innapi_get_all_property_namesRefactoring the prototype climb to go through a
JSValueplusNAPI_RETURN_IF_EXCEPTION(env);ensures any exception fromgetPrototype(globalObject)is converted into anapi_pending_exceptioninstead of leaking through the VM, while preserving the existingnull‑prototype break behavior.src/bun.js/test/ScopeFunctions.zig (1)
441-458: PropagatinggetPrototypeerrors correctly inbindUsing
try (try value.getPrototype(globalThis))ensures both prototype lookup andsetPrototypeDirectare error‑checked and propagated through thebun.JSError!JSValueresult ofbind, instead of silently swallowing failures. This aligns with the project’sJSError!Thandling guidelines. Based on learnings, this is the intended pattern.src/bun.js/test/pretty_format.zig (1)
716-748: Properly unwrapping error-awaregetPrototypeinPropertyIterator.handleFirstPropertySwitching to
try (try value.getPrototype(globalThis)).getNameProperty(...)makes prototype name lookup fully error‑aware: any failure in retrieving the prototype or its name now propagates through thebun.JSError!voidresult instead of being ignored, while preserving the previous formatting behavior for non‑Objectprototypes. Based on learnings, this is the correct way to handleJSError!JSValue.
| it("stack overflow exception checks", () => { | ||
| function probe(value) { | ||
| let originalPrototype, newPrototype; | ||
| let handler = { | ||
| set(target, key, value, receiver) { | ||
| return Reflect.set(target, key, value, receiver); | ||
| }, | ||
| }; | ||
| originalPrototype = Object.getPrototypeOf(value); | ||
| newPrototype = new Proxy(originalPrototype, handler); | ||
| Object.setPrototypeOf(value, newPrototype); | ||
| } | ||
| class Foo { | ||
| get bar() { | ||
| Bun.inspect(this); | ||
| } | ||
| } | ||
| const foo = new Foo(); | ||
| probe(foo); | ||
| expect(() => { | ||
| foo.bar(Foo, foo); | ||
| }).toThrow("Maximum call stack size exceeded"); | ||
| }); |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
New regression test for inspect stack overflow looks good; consider silencing the getter lint
The "stack overflow exception checks" test correctly exercises a recursive Bun.inspect path via a proxy‑wrapped prototype and asserts that it now surfaces as "Maximum call stack size exceeded" instead of crashing, which matches the PR goal.
Static analysis is flagging the get bar() accessor for not returning a value. While this is valid JS (it implicitly returns undefined), you might either:
- make the intent explicit:
class Foo {
get bar() {
return Bun.inspect(this);
}
}- or add a Biome ignore comment for this getter, if you prefer the current shape.
Both keep the test behavior while satisfying the linter.
🧰 Tools
🪛 Biome (2.1.2)
[error] 98-100: This getter should return a value.
(lint/suspicious/useGetterReturn)
🤖 Prompt for AI Agents
In test/js/bun/util/inspect.test.js around lines 85 to 107, the getter get bar()
is flagged by the linter for not returning a value; update the getter to
explicitly return Bun.inspect(this) (i.e., make the intent explicit) or add the
appropriate Biome/linter ignore comment above the getter to silence the warning
while preserving the test behavior.
The getPrototype function was missing a proper exception check using DECLARE_THROW_SCOPE and RETURN_IF_EXCEPTION. This fixes exception validation when BUN_JSC_validateExceptionChecks is enabled. Also fixed the exception check pattern in forEachPropertyImpl to check for exceptions immediately after getPrototype returns, rather than only in the else branch (when getPrototype returns null/falsy). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
UpdateAdded additional exception check fixes in
WebKit Fix RequiredThe remaining exception check failure is in WebKit's The issue is at line 1248-1249 in if (getPrototypeOfMethod.isUndefined())
RELEASE_AND_RETURN(scope, target->getPrototype(globalObject));
Once the WebKit fix is merged and a new WebKit build is used, the test should pass with |
What does this PR do?
Fixes ENG-21685
How did you verify your code works?
Added a minimized test that previously would crash in
Bun.inspect