Rename Zig-prefixed names in the JSC bindings to Bun equivalents#31822
Rename Zig-prefixed names in the JSC bindings to Bun equivalents#31822robobun wants to merge 22 commits into
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThis PR renames JSC-facing Zig-prefixed global object, exception, stack, source-provider, and related binding surfaces to Bun-prefixed names across generators, Rust, Zig, C++, headers, runtime modules, build scripts, and documentation. ChangesBun JSC runtime rename
Suggested reviewers
Comment |
|
Updated 9:48 PM PT - Jun 18th, 2026
❌ @robobun, your commit ba9836d has 3 failures in
🧪 To try this PR locally: bunx bun-pr 31822That installs a local version of the PR into your bun-31822 --bun |
|
This PR may be a duplicate of:
🤖 Generated with Claude Code |
|
Not a coincidence: #30747 is the superset rename (all Zig-prefixed identifiers) but it is currently conflicting and stacked on #30683. This PR is the same ZigGlobalObject -> BunGlobalObject naming, rebuilt fresh against main, and is being extended to cover the remaining Zig-prefixed files in src/jsc/bindings (SourceProvider, Exception, GeneratedCode, LazyStaticFunctions) plus the namespace Zig -> Bun merge, using the same target names as #30747. The ZigString -> UnsafeStringView and ZIG_EXPORT -> RUST_EXPORT sweeps remain in #30747's scope. |
robobun
changed the title
|
Extended per request: namespace Zig is now fully merged into namespace Bun, and the remaining Zig-prefixed binding files (SourceProvider, Exception, GeneratedCode, LazyStaticFunctions) plus the C ABI exception types are renamed on both the C++ and Rust sides. ZigString and the ZIG_EXPORT macro family remain with #30747. |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
I didn't find any issues with the rename itself, but this is a 282-file change spanning the C++/Rust/Zig FFI boundary with a few hand-fixed non-mechanical bits (and CI is currently red on the musl build-cpp jobs), so it's worth a human pass before merge.
Extended reasoning...
Overview
This PR mechanically renames Zig::GlobalObject → Bun::GlobalObject (and ZigGlobalObject.{h,cpp,lut.txt} → BunGlobalObject.*, plus the Zig__GlobalObject__* / ZigGlobalObject__* extern "C" symbols) across 282 files. It touches the core JSC global object class, the codegen templates that emit references to it, the Rust/Zig FFI declarations, build scripts, leaksan suppressions, and docs. The diff is overwhelmingly mechanical find-and-replace, and the author confirmed git grep for the old names is now empty.
Security risks
None identified. This is a pure rename of an internal C++ class and its linker symbols; no auth, crypto, permission, or input-handling logic is changed. The one behavior change (NodeModuleModule's Module constructor now uses defaultGlobalObject() instead of static-casting the lexical global) is a defensive fix for node:vm contexts and is called out in the description.
Level of scrutiny
High, for two reasons. First, the global object is the most central type in Bun's JSC bindings — every extern "C" symbol rename must match on all three sides (C++, Rust, Zig) or the link fails or, worse, silently mismatches. Second, the PR explicitly mixes in several non-mechanical hand-fixes: the empty namespace Zig {} shim in BunClientData.h to keep using namespace Zig valid, making unsafeEvalNoop static to avoid an ODR collision with NodeVM.cpp, the Zig::NativeFunctionPtr qualification fix in JSWrappingFunction.cpp, and the defaultGlobalObject() change in NodeModuleModule. These are individually small but each one is the kind of thing that only shows up on specific build configurations.
Other factors
CI on commit 387b866 shows the musl build-cpp jobs failing (x64-musl, aarch64-musl, x64-musl-baseline); the latest commit ac64c4e may or may not have re-run yet. The author also noted in the thread that this PR is still being extended to cover more Zig-prefixed files, and it overlaps with the larger #30747. Given the scale, the cross-language symbol renames, the red CI, and the in-flight scope, this should get a human sign-off rather than a bot approval.
robobun
force-pushed
the
farm/50d63c3b/rename-zigglobalobject
branch
from
ac64c4e to
d846f74
Compare
|
CI status: every lane is green except :windows: x64-baseline verify-baseline, which is failing on main too (builds 60403 and 60365 fail identically): the Intel SDE download in that step returns a 0-byte sde.tar.xz and 7-Zip exits 2 before any test runs. Not related to this diff. Summary for review: namespace Zig is fully merged into namespace Bun, the Zig-prefixed binding files and the C ABI exception types are renamed on both the C++ and Rust sides, and review feedback (stale CLAUDE.md mention, Zig*.zig reference-file paths in comments) is addressed. ZigString/ZigStringSlice, ZIG_EXPORT/ZIG_DECL, ZigGeneratedClasses and crate-internal zig_* names are intentionally left for #30747. Ready for a human pass. |
|
CI update: the test-bun lanes on build 60500 all fail on a single file, test/cli/install/bunx.test.ts ("should handle package that requires node 24"). This is external: @angular/cli@22.0.0 was just published with engines.node = "^22.22.3 || ^24.15.0 || >=26.0.0", and Bun reports Node v24.3.0, which satisfies none of those ranges, so the Angular CLI exits 3. The failure reproduces identically with the pre-rename release binary (USE_SYSTEM_BUN=1), so it is unrelated to this diff and will hit every branch including main on its next build. Fixing it likely means bumping REPORTED_NODEJS_VERSION or pinning the test to @angular/cli@21, either of which is a separate change. The windows x64-baseline verify-baseline failure remains the known 0-byte Intel SDE download, also broken on main (builds 60403, 60365). Everything else is green. |
robobun
force-pushed
the
farm/50d63c3b/rename-zigglobalobject
branch
from
27a6dec to
c727d0d
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (4)
src/jsc/ErrorCode.rs (1)
1503-1516:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftDon't export placeholder parser/JSError sentinels under the new
Bun_*ABI names.The updated comment says C++ must not link against these Rust statics until they are derived from the same source as
ErrorCode::from(), but Lines 1513 and 1516 still export exactly thoseBun_*symbols. That means the rename carries forward a real behavior bug: C++ will compare against0xFFFE/0xFFFD, whileErrorCode::from()never produces those values, so parser-error / JS-error-object detection silently stops matching. Either derive these exports from the same anyerror source asfrom(), or keep the C++ side on the existing authoritative source until that port lands.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/jsc/ErrorCode.rs` around lines 1503 - 1516, The two Rust statics Bun_ErrorCodeParserError and Bun_ErrorCodeJSErrorObject are being exported under the new Bun_* ABI names but do not match ErrorCode::from() values, so stop exporting these placeholder sentinels: remove or rename the #[unsafe(no_mangle)] exports for Bun_ErrorCodeParserError and Bun_ErrorCodeJSErrorObject (i.e., make them private/internal rust statics or drop the no_mangle so C++ cannot link against them), or alternatively change their initialization to derive the same anyerror-backed u16 that ErrorCode::from() uses (e.g., obtain the value from the same bun_core::Error anyerror interning path) and only then retain the Bun_* ABI export; reference symbols: Bun_ErrorCodeParserError, Bun_ErrorCodeJSErrorObject, ErrorCode::PARSER_ERROR, ErrorCode::JS_ERROR_OBJECT, and ErrorCode::from().src/jsc/bindings/ImportMetaObject.cpp (1)
295-306:⚠️ Potential issue | 🟠 Major | ⚡ Quick winGuard nullable
dynamicDowncastresult before first dereference.Line 295 uses
dynamicDowncast, but Line 305 dereferencesglobalObjectbefore the null-check at Line 317. That can crash on non-Bun globals.🔧 Suggested fix
- if (globalObject->onLoadPlugins.hasVirtualModules()) { + if (globalObject && globalObject->onLoadPlugins.hasVirtualModules()) { if (moduleName.isString()) { auto moduleString = moduleName.toWTFString(globalObject); if (auto resolvedString = globalObject->onLoadPlugins.resolveVirtualModule(moduleString, from.toWTFString(globalObject))) { if (moduleString == resolvedString.value()) return JSC::JSValue::encode(moduleName); return JSC::JSValue::encode(jsString(vm, resolvedString.value())); } } }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/jsc/bindings/ImportMetaObject.cpp` around lines 295 - 306, The result of dynamicDowncast<Bun::GlobalObject> stored in globalObject may be null and is dereferenced later; add an immediate null check after the dynamicDowncast (before any use of globalObject, e.g., before accessing globalObject->onLoadPlugins) and handle the null case by returning early (using the same error/exception flow as other early returns, e.g., via RETURN_IF_EXCEPTION or an empty return) or throwing an appropriate JS exception so we never dereference a null pointer in ImportMetaObject.cpp; update the logic around the existing RETURN_IF_EXCEPTION and subsequent uses of moduleName/from/isESM/isRequireDotResolve/userPathList to assume globalObject is non-null after the guard.src/jsc/bindings/BunGlobalObject.cpp (1)
3298-3327: 🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick winDelete the commented-out legacy
GlobalObjectimplementation instead of renaming it.This block is dead code, and keeping the renamed Zig-era implementation here makes the file harder to audit during the rest of this migration. Please remove it rather than updating identifiers inside the comments.
As per coding guidelines, "Delete dead code in the same PR that makes it dead" and "Comments carry only durable non-obvious content."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/jsc/bindings/BunGlobalObject.cpp` around lines 3298 - 3327, Remove the entire commented-out legacy GlobalObject implementation block (the commented definitions for GlobalObject::destroy, GlobalObject::visitChildrenImpl, and the trailing DEFINE_VISIT_CHILDREN(Bun::GlobalObject);) instead of editing identifiers in comments; simply delete that dead-code comment region so only the active Zig-era implementation remains, and run a quick grep for GlobalObject::destroy, visitChildrenImpl, and DEFINE_VISIT_CHILDREN to ensure no needed code was accidentally removed.src/jsc/bindings/NodeFSStatFSBinding.cpp (1)
364-377:⚠️ Potential issue | 🟠 Major | ⚡ Quick winUse
defaultGlobalObject()for the subclass realm.
getFunctionRealm()can return a non-Bun global here, so thestatic_cast<Bun::GlobalObject*>on Line 372 can readm_JSStatFS*ClassStructurefrom the wrong object layout. This is the same cross-realm bug class the PR already fixed elsewhere withdefaultGlobalObject().Suggested fix
- auto* functionGlobalObject = static_cast<Bun::GlobalObject*>( - // ShadowRealm functions belong to a different global object. - getFunctionRealm(lexicalGlobalObject, newTarget)); + auto* functionGlobalObject = defaultGlobalObject( + // ShadowRealm functions belong to a different global object. + getFunctionRealm(lexicalGlobalObject, newTarget));🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/jsc/bindings/NodeFSStatFSBinding.cpp` around lines 364 - 377, The code currently static_casts the result of getFunctionRealm(lexicalGlobalObject, newTarget) to Bun::GlobalObject*, which can yield a non-Bun layout; instead call defaultGlobalObject on the realm returned by getFunctionRealm so you get a Bun::GlobalObject* in the subclass path. Replace the static_cast line building functionGlobalObject with something like: auto* functionGlobalObject = defaultGlobalObject(getFunctionRealm(lexicalGlobalObject, newTarget)), then pass that functionGlobalObject into getStatFSStructure<isBigInt> and createSubclassStructure calls (symbols: getFunctionRealm, defaultGlobalObject, functionGlobalObject, getStatFSStructure<isBigInt>, createSubclassStructure, lexicalGlobalObject, newTarget).
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/codegen/generate-classes.ts`:
- Around line 659-663: The generated call() methods currently reinterpret_cast
the lexicalGlobalObject to Bun::GlobalObject and dereference Bun-only fields;
replace that with using Bun::defaultGlobalObject(lexicalGlobalObject) to obtain
a safe Bun::GlobalObject pointer (same approach as construct()), then get the VM
from that object and use DECLARE_THROW_SCOPE(vm); update the call()
implementations (and the other similar block around the other occurrence) to
mirror the construct() path by calling defaultGlobalObject(...) instead of
reinterpret_cast and proceed as before.
- Around line 773-775: The C++ thunks like ${typeName}__getConstructor must not
narrow their ABI parameter to Bun::GlobalObject*; revert the generated function
signatures to accept the generic JSC::JSGlobalObject* (or JSGlobalObject*) that
callers (Zig/Rust) expect so we don't downcast foreign globals; update the
signature for ${typeName}__getConstructor and apply the same pattern to
__createWithValues, __createWithInitialValues, and
__createWithValuesAndInitialValues so each uses the generic JSGlobalObject* and
then obtain the Bun-specific constructor via the
className(typeName)Constructor() accessor inside the function body.
In `@src/jsc/bindings/BunException.cpp`:
- Around line 2-5: Update the stale header that says “Zig exceptions” to reflect
the rename (e.g., “Bun exceptions” or “BunException”) in the top comment of
BunException.cpp and any other occurrences in this file; locate the header block
that begins with "BunException handling and error processing utilities" and
replace references to "Zig exceptions" with the correct term, and also sweep the
file for any other stray mentions of "Zig" (including function comments around
the exception conversion utilities) and update them to the new name.
In `@src/jsc/bindings/BunObject.cpp`:
- Line 623: Rename the misleading local variable zigGlobalObject to
bunGlobalObject wherever it's declared from
uncheckedDowncast<Bun::GlobalObject>(globalObject); specifically update the
declaration at the shown occurrence and the same pattern at the other
occurrences (lines referenced in the review) so any usage referring to
zigGlobalObject in functions that work with Bun::GlobalObject now use
bunGlobalObject for consistency with the type; ensure you update all variable
references and keep the uncheckedDowncast<Bun::GlobalObject>(globalObject)
expression unchanged.
In `@src/jsc/bindings/BunProcess.cpp`:
- Around line 392-395: Several public process host functions are directly
downcasting lexicalGlobalObject/globalObject_ to Bun::GlobalObject (e.g.,
Process_functionDlopen, Process_setUncaughtExceptionCaptureCallback,
Process_functionHRTime, Process_functionHRTimeBigInt, Process_emitWarning,
Process_functionGetReport, Process_functionBinding,
Process_functionLoadBuiltinModule); change those downcasts to normalize the
global object using defaultGlobalObject(...) (or add an inherits guard) like the
other process entry points do, then use the returned GlobalObject* (or bail
out/throw if null) before calling DECLARE_THROW_SCOPE/getVM or accessing
napiModuleRegisterCallCount to ensure safe, consistent global-object handling
across these functions.
In `@src/jsc/bindings/JSBufferList.cpp`:
- Line 467: The return contains an unnecessary static_cast of globalObject to
Bun::GlobalObject*; simply return globalObject->JSBufferList() instead. Update
the function in JSBufferList.cpp to remove static_cast<Bun::GlobalObject*> and
return globalObject->JSBufferList(), keeping the original return type unchanged
and relying on the existing globalObject parameter type.
In `@src/jsc/bindings/SQLClient.cpp`:
- Around line 138-139: Rename the local variable zigGlobal to reflect its actual
type Bun::GlobalObject* (e.g., bunGlobal or globalObjectPtr) wherever it's
declared and used; specifically update the declaration that currently reads
"Bun::GlobalObject* zigGlobal =
uncheckedDowncast<Bun::GlobalObject>(globalObject);" and all subsequent uses
such as the call to JSBufferSubclassStructure() and the other occurrences
mentioned (around the later block at the same file). Ensure you update every
reference (including the uses at the later 178-179 region) so grep/identifiers
are consistent with the new Bun::GlobalObject* type.
In `@src/jsc/VirtualMachine.rs`:
- Around line 3775-3777: Update the stale symbol name in the comment that
mentions the old constructor: replace `BunGlobalObject__create` with
`Bun__GlobalObject__create` in the comment block near the global-init logic (the
comment that explains routing through `init` then swapping the global), and
sweep the same PR for any other comments/JSDoc that still reference the old
`BunGlobalObject__create` symbol so all documentation matches the current
constructor name (`Bun__GlobalObject__create`).
---
Outside diff comments:
In `@src/jsc/bindings/BunGlobalObject.cpp`:
- Around line 3298-3327: Remove the entire commented-out legacy GlobalObject
implementation block (the commented definitions for GlobalObject::destroy,
GlobalObject::visitChildrenImpl, and the trailing
DEFINE_VISIT_CHILDREN(Bun::GlobalObject);) instead of editing identifiers in
comments; simply delete that dead-code comment region so only the active Zig-era
implementation remains, and run a quick grep for GlobalObject::destroy,
visitChildrenImpl, and DEFINE_VISIT_CHILDREN to ensure no needed code was
accidentally removed.
In `@src/jsc/bindings/ImportMetaObject.cpp`:
- Around line 295-306: The result of dynamicDowncast<Bun::GlobalObject> stored
in globalObject may be null and is dereferenced later; add an immediate null
check after the dynamicDowncast (before any use of globalObject, e.g., before
accessing globalObject->onLoadPlugins) and handle the null case by returning
early (using the same error/exception flow as other early returns, e.g., via
RETURN_IF_EXCEPTION or an empty return) or throwing an appropriate JS exception
so we never dereference a null pointer in ImportMetaObject.cpp; update the logic
around the existing RETURN_IF_EXCEPTION and subsequent uses of
moduleName/from/isESM/isRequireDotResolve/userPathList to assume globalObject is
non-null after the guard.
In `@src/jsc/bindings/NodeFSStatFSBinding.cpp`:
- Around line 364-377: The code currently static_casts the result of
getFunctionRealm(lexicalGlobalObject, newTarget) to Bun::GlobalObject*, which
can yield a non-Bun layout; instead call defaultGlobalObject on the realm
returned by getFunctionRealm so you get a Bun::GlobalObject* in the subclass
path. Replace the static_cast line building functionGlobalObject with something
like: auto* functionGlobalObject =
defaultGlobalObject(getFunctionRealm(lexicalGlobalObject, newTarget)), then pass
that functionGlobalObject into getStatFSStructure<isBigInt> and
createSubclassStructure calls (symbols: getFunctionRealm, defaultGlobalObject,
functionGlobalObject, getStatFSStructure<isBigInt>, createSubclassStructure,
lexicalGlobalObject, newTarget).
In `@src/jsc/ErrorCode.rs`:
- Around line 1503-1516: The two Rust statics Bun_ErrorCodeParserError and
Bun_ErrorCodeJSErrorObject are being exported under the new Bun_* ABI names but
do not match ErrorCode::from() values, so stop exporting these placeholder
sentinels: remove or rename the #[unsafe(no_mangle)] exports for
Bun_ErrorCodeParserError and Bun_ErrorCodeJSErrorObject (i.e., make them
private/internal rust statics or drop the no_mangle so C++ cannot link against
them), or alternatively change their initialization to derive the same
anyerror-backed u16 that ErrorCode::from() uses (e.g., obtain the value from the
same bun_core::Error anyerror interning path) and only then retain the Bun_* ABI
export; reference symbols: Bun_ErrorCodeParserError, Bun_ErrorCodeJSErrorObject,
ErrorCode::PARSER_ERROR, ErrorCode::JS_ERROR_OBJECT, and ErrorCode::from().
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 2d5dd5c3-4e23-4ccc-920a-5a5d7b104d14
📒 Files selected for processing (300)
.claude/skills/implementing-jsc-classes-cpp/SKILL.md.gitattributesCLAUDE.mdscripts/build/codegen.tsscripts/build/unified.tssrc/ast_jsc/lib.rssrc/bun_bin/phase_c_exports.rssrc/bun_core/string/mod.rssrc/bundler/analyze_transpiled_module.rssrc/bundler_jsc/analyze_jsc.rssrc/codegen/bundle-functions.tssrc/codegen/cppbind.tssrc/codegen/generate-classes.tssrc/codegen/generate-host-exports.tssrc/codegen/generate-js2native.tssrc/codegen/generate-jssink.tssrc/codegen/shared-types.tssrc/event_loop/README.mdsrc/http_jsc/websocket_client.rssrc/js/builtins/shell.tssrc/js/node/worker_threads.tssrc/jsc/BunErrorType.rssrc/jsc/BunException.rssrc/jsc/BunStackFrame.rssrc/jsc/BunStackFrameCode.rssrc/jsc/BunStackFramePosition.rssrc/jsc/BunStackTrace.rssrc/jsc/CommonStrings.rssrc/jsc/ConsoleObject.rssrc/jsc/DOMFormData.rssrc/jsc/Debugger.rssrc/jsc/ErrorCode.rssrc/jsc/Errorable.rssrc/jsc/Exception.rssrc/jsc/FetchHeaders.rssrc/jsc/JSGlobalObject.rssrc/jsc/JSGlobalObject.zigsrc/jsc/JSValue.rssrc/jsc/ModuleLoader.rssrc/jsc/ResolvedSource.rssrc/jsc/RuntimeTranspilerStore.rssrc/jsc/SavedSourceMap.rssrc/jsc/VM.rssrc/jsc/VirtualMachine.rssrc/jsc/VirtualMachine.zigsrc/jsc/array_buffer.rssrc/jsc/bindings/AsymmetricKeyValue.cppsrc/jsc/bindings/AsyncContextFrame.cppsrc/jsc/bindings/BakeAdditionsToGlobalObject.cppsrc/jsc/bindings/BunAnalyzeTranspiledModule.cppsrc/jsc/bindings/BunAnalyzeTranspiledModule.hsrc/jsc/bindings/BunCPUProfiler.cppsrc/jsc/bindings/BunClientData.cppsrc/jsc/bindings/BunClientData.hsrc/jsc/bindings/BunCommonStrings.cppsrc/jsc/bindings/BunDebugger.cppsrc/jsc/bindings/BunException.cppsrc/jsc/bindings/BunGeneratedCode.cppsrc/jsc/bindings/BunGlobalObject.cppsrc/jsc/bindings/BunGlobalObject.hsrc/jsc/bindings/BunGlobalObject.lut.txtsrc/jsc/bindings/BunGlobalScope.cppsrc/jsc/bindings/BunHttp2CommonStrings.cppsrc/jsc/bindings/BunLazyStaticFunctions-inlines.hsrc/jsc/bindings/BunLazyStaticFunctions.hsrc/jsc/bindings/BunMarkdownMeta.cppsrc/jsc/bindings/BunMarkdownMeta.hsrc/jsc/bindings/BunMarkdownTagStrings.cppsrc/jsc/bindings/BunObject.cppsrc/jsc/bindings/BunPlugin.cppsrc/jsc/bindings/BunPlugin.hsrc/jsc/bindings/BunProcess.cppsrc/jsc/bindings/BunProcess.hsrc/jsc/bindings/BunProcessReportObjectWindows.cppsrc/jsc/bindings/BunSecureContextCache.cppsrc/jsc/bindings/BunSecureContextCache.hsrc/jsc/bindings/BunSourceProvider.cppsrc/jsc/bindings/BunSourceProvider.hsrc/jsc/bindings/BunString.cppsrc/jsc/bindings/BundlerMetafile.cppsrc/jsc/bindings/CallSite.cppsrc/jsc/bindings/CallSite.hsrc/jsc/bindings/CallSitePrototype.cppsrc/jsc/bindings/CallSitePrototype.hsrc/jsc/bindings/CodeCoverage.cppsrc/jsc/bindings/ConsoleObject.hsrc/jsc/bindings/DOMWrapperWorld.cppsrc/jsc/bindings/DOMWrapperWorld.hsrc/jsc/bindings/ErrorCode.cppsrc/jsc/bindings/ErrorCode.hsrc/jsc/bindings/ErrorStackFrame.cppsrc/jsc/bindings/ErrorStackFrame.hsrc/jsc/bindings/ErrorStackTrace.cppsrc/jsc/bindings/ErrorStackTrace.hsrc/jsc/bindings/EventLoopTaskNoContext.hsrc/jsc/bindings/ExposeNodeModuleGlobals.cppsrc/jsc/bindings/FormatStackTraceForJS.cppsrc/jsc/bindings/FormatStackTraceForJS.hsrc/jsc/bindings/FuzzilliREPRL.cppsrc/jsc/bindings/HTMLEntryPoint.cppsrc/jsc/bindings/IPC.cppsrc/jsc/bindings/ImportMetaObject.cppsrc/jsc/bindings/ImportMetaObject.hsrc/jsc/bindings/InspectorBunFrontendDevServerAgent.cppsrc/jsc/bindings/InspectorHTTPServerAgent.cppsrc/jsc/bindings/InspectorLifecycleAgent.cppsrc/jsc/bindings/InspectorLifecycleAgent.hsrc/jsc/bindings/InspectorTestReporterAgent.cppsrc/jsc/bindings/InternalForTesting.cppsrc/jsc/bindings/InternalForTesting.hsrc/jsc/bindings/InternalModuleRegistry.cppsrc/jsc/bindings/IsolatedModuleCache.cppsrc/jsc/bindings/IsolatedModuleCache.hsrc/jsc/bindings/JS2Native.cppsrc/jsc/bindings/JSBakeResponse.cppsrc/jsc/bindings/JSBakeResponse.hsrc/jsc/bindings/JSBuffer.cppsrc/jsc/bindings/JSBufferList.cppsrc/jsc/bindings/JSBufferList.hsrc/jsc/bindings/JSBunRequest.cppsrc/jsc/bindings/JSBunRequest.hsrc/jsc/bindings/JSBundlerPlugin.cppsrc/jsc/bindings/JSBundlerPlugin.hsrc/jsc/bindings/JSCTestingHelpers.cppsrc/jsc/bindings/JSCTestingHelpers.hsrc/jsc/bindings/JSCommonJSExtensions.cppsrc/jsc/bindings/JSCommonJSModule.cppsrc/jsc/bindings/JSCommonJSModule.hsrc/jsc/bindings/JSDOMExceptionHandling.cppsrc/jsc/bindings/JSDOMFile.cppsrc/jsc/bindings/JSDOMGlobalObject.cppsrc/jsc/bindings/JSDOMGlobalObject.hsrc/jsc/bindings/JSDOMWrapper.hsrc/jsc/bindings/JSDOMWrapperCache.cppsrc/jsc/bindings/JSEnvironmentVariableMap.cppsrc/jsc/bindings/JSEnvironmentVariableMap.hsrc/jsc/bindings/JSFFIFunction.cppsrc/jsc/bindings/JSFFIFunction.hsrc/jsc/bindings/JSMockFunction.cppsrc/jsc/bindings/JSMockFunction.hsrc/jsc/bindings/JSNodePerformanceHooksHistogram.cppsrc/jsc/bindings/JSNodePerformanceHooksHistogramConstructor.cppsrc/jsc/bindings/JSNodePerformanceHooksHistogramPrototype.hsrc/jsc/bindings/JSPropertyIterator.cppsrc/jsc/bindings/JSReactElement.cppsrc/jsc/bindings/JSReactElement.hsrc/jsc/bindings/JSS3File.cppsrc/jsc/bindings/JSS3File.hsrc/jsc/bindings/JSSecrets.cppsrc/jsc/bindings/JSSocketAddressDTO.cppsrc/jsc/bindings/JSSocketAddressDTO.hsrc/jsc/bindings/JSStringDecoder.cppsrc/jsc/bindings/JSWrappingFunction.cppsrc/jsc/bindings/JSWrappingFunction.hsrc/jsc/bindings/JSX509Certificate.cppsrc/jsc/bindings/JSX509Certificate.hsrc/jsc/bindings/JSX509CertificateConstructor.cppsrc/jsc/bindings/JSX509CertificateConstructor.hsrc/jsc/bindings/JSX509CertificatePrototype.cppsrc/jsc/bindings/ModuleLoader.cppsrc/jsc/bindings/ModuleLoader.hsrc/jsc/bindings/NapiClass.cppsrc/jsc/bindings/NapiRef.cppsrc/jsc/bindings/NapiWeakValue.cppsrc/jsc/bindings/NativePromiseContext.cppsrc/jsc/bindings/NodeAsyncHooks.cppsrc/jsc/bindings/NodeAsyncHooks.hsrc/jsc/bindings/NodeDirent.cppsrc/jsc/bindings/NodeFSStatBinding.cppsrc/jsc/bindings/NodeFSStatFSBinding.cppsrc/jsc/bindings/NodeFetch.cppsrc/jsc/bindings/NodeFetch.hsrc/jsc/bindings/NodeHTTP.cppsrc/jsc/bindings/NodeHTTP.hsrc/jsc/bindings/NodeTLS.cppsrc/jsc/bindings/NodeTLS.hsrc/jsc/bindings/NodeTimerObject.cppsrc/jsc/bindings/NodeURL.cppsrc/jsc/bindings/NodeURL.hsrc/jsc/bindings/NodeVM.cppsrc/jsc/bindings/NodeVM.hsrc/jsc/bindings/NodeValidator.cppsrc/jsc/bindings/NodeValidator.hsrc/jsc/bindings/Path.cppsrc/jsc/bindings/Path.hsrc/jsc/bindings/ProcessBindingFs.cppsrc/jsc/bindings/ProcessBindingHTTPParser.cppsrc/jsc/bindings/ProcessBindingTTYWrap.cppsrc/jsc/bindings/ProcessBindingTTYWrap.hsrc/jsc/bindings/ProcessBindingUV.cppsrc/jsc/bindings/SQLClient.cppsrc/jsc/bindings/ScriptExecutionContext.cppsrc/jsc/bindings/ServerRouteList.cppsrc/jsc/bindings/ServerRouteList.hsrc/jsc/bindings/ShellBindings.cppsrc/jsc/bindings/StrongRef.cppsrc/jsc/bindings/URLSearchParams.cppsrc/jsc/bindings/Undici.cppsrc/jsc/bindings/Undici.hsrc/jsc/bindings/UtilInspect.cppsrc/jsc/bindings/bindings.cppsrc/jsc/bindings/headers-cpp.hsrc/jsc/bindings/headers-handwritten.hsrc/jsc/bindings/headers.hsrc/jsc/bindings/helpers.hsrc/jsc/bindings/napi.cppsrc/jsc/bindings/napi.hsrc/jsc/bindings/napi_external.hsrc/jsc/bindings/napi_handle_scope.cppsrc/jsc/bindings/napi_handle_scope.hsrc/jsc/bindings/napi_type_tag.cppsrc/jsc/bindings/node/JSNodeHTTPServerSocket.cppsrc/jsc/bindings/node/JSNodeHTTPServerSocket.hsrc/jsc/bindings/node/JSNodeHTTPServerSocketPrototype.cppsrc/jsc/bindings/node/crypto/CryptoUtil.cppsrc/jsc/bindings/node/crypto/CryptoUtil.hsrc/jsc/bindings/node/crypto/JSCipher.cppsrc/jsc/bindings/node/crypto/JSDiffieHellman.cppsrc/jsc/bindings/node/crypto/JSDiffieHellmanGroup.cppsrc/jsc/bindings/node/crypto/JSDiffieHellmanGroupConstructor.cppsrc/jsc/bindings/node/crypto/JSECDH.cppsrc/jsc/bindings/node/crypto/JSKeyObject.cppsrc/jsc/bindings/node/crypto/JSKeyObjectConstructor.cppsrc/jsc/bindings/node/crypto/JSPrivateKeyObject.cppsrc/jsc/bindings/node/crypto/JSPublicKeyObject.cppsrc/jsc/bindings/node/crypto/JSSecretKeyObject.cppsrc/jsc/bindings/node/crypto/JSSign.cppsrc/jsc/bindings/node/crypto/JSVerify.cppsrc/jsc/bindings/node/crypto/KeyObject.cppsrc/jsc/bindings/node/crypto/node_crypto_binding.cppsrc/jsc/bindings/node/crypto/node_crypto_binding.hsrc/jsc/bindings/node/http/JSConnectionsListConstructor.cppsrc/jsc/bindings/node/http/JSHTTPParserConstructor.cppsrc/jsc/bindings/node/http/JSHTTPParserPrototype.cppsrc/jsc/bindings/node/http/NodeHTTPParser.cppsrc/jsc/bindings/objects.hsrc/jsc/bindings/root-pch.hsrc/jsc/bindings/sqlite/JSSQLStatement.cppsrc/jsc/bindings/sqlite/JSSQLStatement.hsrc/jsc/bindings/v8/V8Array.cppsrc/jsc/bindings/v8/V8Context.hsrc/jsc/bindings/v8/V8Function.cppsrc/jsc/bindings/v8/V8Isolate.cppsrc/jsc/bindings/v8/V8Isolate.hsrc/jsc/bindings/v8/V8Object.cppsrc/jsc/bindings/v8/shim/FunctionTemplate.cppsrc/jsc/bindings/v8/shim/GlobalInternals.cppsrc/jsc/bindings/v8/shim/GlobalInternals.hsrc/jsc/bindings/v8/v8.hsrc/jsc/bindings/webcore/AbortController.hsrc/jsc/bindings/webcore/AbortSignal.hsrc/jsc/bindings/webcore/DOMIsoSubspaces.hsrc/jsc/bindings/webcore/JSCallbackData.cppsrc/jsc/bindings/webcore/JSDOMConstructorBase.hsrc/jsc/bindings/webcore/JSDOMConvertBase.hsrc/jsc/bindings/webcore/JSDOMGlobalObjectInlines.hsrc/jsc/bindings/webcore/JSErrorEvent.cppsrc/jsc/bindings/webcore/JSEventEmitter.cppsrc/jsc/bindings/webcore/JSEventEmitterCustom.cppsrc/jsc/bindings/webcore/JSEventListener.cppsrc/jsc/bindings/webcore/JSEventTargetCustom.cppsrc/jsc/bindings/webcore/JSMIMEBindings.cppsrc/jsc/bindings/webcore/JSMIMEBindings.hsrc/jsc/bindings/webcore/JSMIMEParams.cppsrc/jsc/bindings/webcore/JSMIMEParams.hsrc/jsc/bindings/webcore/JSMIMEType.cppsrc/jsc/bindings/webcore/JSPerformance.cppsrc/jsc/bindings/webcore/JSPerformanceObserverCallback.cppsrc/jsc/bindings/webcore/JSReadableStream.cppsrc/jsc/bindings/webcore/JSWebSocket.cppsrc/jsc/bindings/webcore/JSWebSocket.hsrc/jsc/bindings/webcore/MessagePort.cppsrc/jsc/bindings/webcore/PerformanceMark.cppsrc/jsc/bindings/webcore/PerformanceObserver.cppsrc/jsc/bindings/webcore/ReadableStream.cppsrc/jsc/bindings/webcore/SerializedScriptValue.cppsrc/jsc/bindings/webcore/WebSocket.cppsrc/jsc/bindings/webcore/Worker.cppsrc/jsc/bindings/webcore/Worker.hsrc/jsc/bindings/xxhash3.cppsrc/jsc/bindings/xxhash3_testing.cppsrc/jsc/headergen/sizegen.cppsrc/jsc/host_fn.rssrc/jsc/jsc.zigsrc/jsc/lib.rssrc/jsc/modules/AbortControllerModuleModule.hsrc/jsc/modules/BunAppModule.hsrc/jsc/modules/BunJSCModule.hsrc/jsc/modules/BunObjectModule.hsrc/jsc/modules/BunTestModule.hsrc/jsc/modules/NodeBufferModule.hsrc/jsc/modules/NodeConstantsModule.hsrc/jsc/modules/NodeModuleModule.cppsrc/jsc/modules/NodeModuleModule.hsrc/jsc/modules/NodeProcessModule.hsrc/jsc/modules/NodeStringDecoderModule.hsrc/jsc/modules/NodeTTYModule.cppsrc/jsc/modules/NodeTTYModule.hsrc/jsc/modules/NodeUtilTypesModule.cppsrc/jsc/modules/NodeUtilTypesModule.h
robobun
force-pushed
the
farm/50d63c3b/rename-zigglobalobject
branch
from
fd6338b to
50d99c9
Compare
|
Final CI status for build 60623 (50d99c9): every build lane passed on all platforms, and the only failure is windows x64-baseline verify-baseline. That lane fails identically on main: build 60590 at 8553428 (the exact commit this branch is rebased on) has the same single failure out of 30 statuses. The step's Intel SDE download returns a 0-byte sde.tar.xz and 7-Zip exits 2 before any test runs, so it cannot be related to this rename diff. A retrigger was already spent on the same infra failure earlier, so I will not push another. The diff is green and review threads are resolved; this is ready for a maintainer. |
|
Same story on build 60643 (af18345, the bare zig local rename): every build lane passed and the only failure is windows x64-baseline verify-baseline, the known Intel SDE infra issue (0-byte sde.tar.xz download, 7-Zip exit 2) that fails identically on main's build 60590 at 8553428. Not caused by this diff and a retrigger was already spent on it earlier. All review threads are resolved and the diff is green; ready for a maintainer. |
|
Final tally for build 60643 (af18345) now that the test lanes finished. Every failure is pre-existing or infra, none touch this rename:
All build lanes green on every platform, review threads resolved, retrigger already spent. The diff itself is green; ready for a maintainer. |
The class dates to when Bun's runtime was written in Zig and the "Zig"
prefix meant "the global object that bridges to Zig code". The runtime
has since been ported, the prefix is misleading, and the header carried
a TODO asking for this rename since 2023.
- Zig::GlobalObject and Zig::EvalGlobalObject move to namespace Bun
- ZigGlobalObject.{h,cpp,lut.txt} become BunGlobalObject.{h,cpp,lut.txt}
- extern "C" symbols Zig__GlobalObject__* become Bun__GlobalObject__*,
ZigGlobalObject__* become BunGlobalObject__*, and
Bun__ZigGlobalObject__uvLoop becomes Bun__GlobalObject__uvLoop
- codegen templates, build scripts, leak suppressions and docs updated
No behavior change.
The constructor static_cast the lexical global to Bun::GlobalObject, which is wrong when invoked from a non-Bun global such as a node:vm context. Use defaultGlobalObject() so those callers fall back to the main global's CommonJSModule structure instead of reading through a bogus pointer.
…xed binding files
Continues the rename started with ZigGlobalObject:
- namespace Zig is gone; all members (SourceProvider, JSFFIFunction,
CallSite, ImportMetaObject, JSCStackTrace, string helpers, ...) now
live in namespace Bun
- ZigSourceProvider.{h,cpp}, ZigException.cpp, ZigGeneratedCode.cpp and
ZigLazyStaticFunctions{,-inlines}.h are renamed to Bun*
- the C ABI exception types (ZigException, ZigStackTrace, ZigStackFrame,
ZigStackFramePosition, ZigStackFrameCode, ZigErrorType, ZigErrorCode)
are renamed to Bun* on both the C++ and Rust sides, along with their
Rust source files and modules
- CommonStringsForZig -> CommonStringsForBun, Zig_ErrorCode* ->
Bun_ErrorCode*, zig__ModuleInfo* and zig__renderDiff -> bun__*
ZigString/ZigStringSlice, ZIG_EXPORT/ZIG_DECL and the crate-internal
zig_* names are left for the larger sweep in #30747.
CLAUDE.md gained another ZigGlobalObject mention upstream between the two rename passes; update it. Also restore the "ported from" and inline comment references in the renamed Rust exception files to point at the Zig*.zig reference files, which keep their original names until they are deleted.
Restore the two quoted zig_exception enum spellings in VirtualMachine.rs doc comments, correct the closing-brace comments on WebCore namespace blocks in JSBufferList.cpp and JSStringDecoder.cpp, and drop the self-referential using namespace Bun directives in ModuleLoader.cpp and KeyObject.cpp that the namespace merge made no-ops.
|
CI status for build 61595 (93d2cf8): the only error-level failure is That failure is environmental, not from this PR. The test runs It will fail on any branch until the test stops tracking The two warning-level annotations ( No failure in this build involves the renamed symbols or files. The diff itself remains green: all build lanes on every platform compile, and earlier runs (60623, 60643) showed the same picture with only pre-existing or infra failures. This should be ready for a maintainer once #31820 lands or the bunx failure is waived. |
|
Update: main was merged into this branch (cdad656), which picks up #32042 skipping |
|
CI status for build 61625 (cdad656, the branch with main merged in): zero test failures so far. The build shows as failing only because 12 test shards (debian 13 aarch64, ubuntu 25.04 aarch64/x64, debian 13 x64) expired in the agent queue before being picked up, and expired jobs count against the build. They have not been retried; my Buildkite token is read-only so I cannot retry them from here. Current job tally: 99 passed, ~175 still queued or running, 12 expired, 0 failed. The only annotations are three flaky tests that passed on retry (fetch-tls-abortsignal-timeout on windows, test/package.json on asan, shell rm on alpine), none related to the rename. If the remaining lanes pass, the only thing standing between this and green is someone with write access clicking retry on the 12 expired shards at https://buildkite.com/bun/bun/builds/61625. |
|
Final picture for build 61625 (cdad656): 270 shards passed, 0 failures related to this PR. The red consists of:
The 11 flaky-test annotations all passed on retry and none touch the rename. Everything red is retry-safe. My Buildkite token is read-only, so this needs someone with write access to hit retry on the expired shards and the darwin job at https://buildkite.com/bun/bun/builds/61625, or a rebuild. |
|
Build 61625 has now fully finished: 271 passed, 2 failed, 13 expired. The one failure that resolved since my last comment is Complete failure inventory, none touching this PR:
All of it is retry-safe; needs someone with Buildkite write access to retry those jobs or rebuild https://buildkite.com/bun/bun/builds/61625. |
|
Merged current main into the branch again (46452b0) to clear the conflicts. One real conflict, in Verification after the merge: the semantic-conflict sweep ( Main also picked up #32072 (auto-retry jobs killed by agent loss) and #32033 (serialized docker service startup), which should address the infra failures that plagued builds 61595 and 61625. |
There was a problem hiding this comment.
5737a4b addresses my last nit on NodeModuleModule.h — nothing further from the bot pass. Deferring to a human given this is a 300-file rename across the C++/Rust FFI boundary in core JSC bindings, with a handful of non-mechanical bits (the defaultGlobalObject() swap in NodeModuleModule.cpp, the static unsafeEvalNoop, the JSC::Exception qualification) that warrant maintainer sign-off.
Extended reasoning...
Overview
This PR mechanically renames Zig-prefixed identifiers in the JSC bindings layer to Bun-prefixed equivalents: Zig::GlobalObject → Bun::GlobalObject, namespace Zig merged into namespace Bun, ZigGlobalObject.{h,cpp,lut.txt} → BunGlobalObject.*, ZigSourceProvider/ZigException/ZigStackTrace/etc. → Bun*, plus the matching extern "C" symbol renames (Zig__GlobalObject__* → Bun__GlobalObject__*, zig__ModuleInfo* → bun__*, etc.) coordinated across C++, Rust, Zig reference files, codegen templates (generate-classes.ts, bundle-functions.ts, cppbind.ts, generate-jssink.ts), build scripts, and docs. 300 files changed. It is the bindings-layer subset of the larger #30747 rename, landed fresh against main.
The PR description enumerates a small set of non-mechanical changes: making unsafeEvalNoop static to avoid a duplicate symbol after the namespace merge, qualifying one JSC::Exception in napi.cpp that became ambiguous, swapping a TODO'd static_cast<Zig::GlobalObject*> for defaultGlobalObject() in the Module constructor in NodeModuleModule.cpp, deleting a long-dead commented-out block in BunGlobalObject.cpp, and moving ~20 forward-decls from namespace Zig to namespace Bun blocks. A follow-up sweep (50d99c9, af18345) also renamed zigGlobal/zigGlobalObject/zig local variables tree-wide.
Security risks
None identified. This is a pure identifier/namespace rename with no changes to authentication, authorization, input handling, or data exposure. The one behavioral change (NodeModuleModule.cpp using defaultGlobalObject() instead of an unchecked static_cast) is a hardening fix for the node:vm foreign-realm case, not a new attack surface.
Level of scrutiny
High. While the change is overwhelmingly mechanical and the compiler/linker enforce most of the correctness (mismatched extern "C" symbols would fail to link; type mismatches would fail to compile), this touches the core runtime: BunGlobalObject.cpp (the global object itself), ModuleLoader.cpp, napi.cpp, bindings.cpp, the codegen templates that produce all generated JS classes, and the C ABI exception/stack-trace types shared between C++ and Rust. The extern "C" symbol renames span the FFI boundary in both directions and must agree exactly across C++, Rust, and the codegen output. The PR also represents a project-level staging decision (landing the bindings subset of #30747 separately) that a maintainer should ratify.
Other factors
- The bug-hunting system found no issues on this run. Across ~10 prior bot review rounds on this PR, every finding was a documentation/cosmetic nit (stale
.zigreference-file paths in comments, redundantnamespace Bunblocks, mis-named local variables) — none were functional bugs. All have been addressed; the most recent (NodeModuleModule.h adjacent-namespace block) is fixed in commit 5737a4b, which I verified against the current file contents. - CodeRabbit raised three out-of-scope suggestions (using
defaultGlobalObject()in more places, narrowing generated ABI signatures) which the author correctly declined as pre-existing behavior unrelated to the rename; CodeRabbit retracted those. - CI has been green on all build lanes across multiple runs; remaining test failures were documented as external (
@angular/cliengines bump, Intel SDE infra, agent-loss expirations) and unrelated to this diff. - The author smoke-tested the renamed code paths (streams, vm, plugins, worker_threads, ffi, Error.prepareStackTrace, bun build) per the PR description.
- No human reviewer has weighed in yet; the author has flagged "ready for a maintainer" several times.
Given the scale, the criticality of the touched files, and the project-level nature of the staging decision relative to #30747, this warrants a human maintainer's approval rather than bot sign-off.
|
CI status for build 61978 (5737a4b): 285 of 286 shards passed. The single failure is the darwin 14 aarch64 test shard, which timed out due to agent environment, not this diff:
All build lanes are green, binary size is unchanged, and the bot review pass is complete with no findings. The diff is ready for maintainer review. |
|
Final CI status for build 62341 (7638aa0, after merging current main): 222 passed, 63 failed, 1 timed out. Every failure is environmental and reproduces on other unrelated PRs that ran in the same window; none are caused by this diff. api.github.com outage (accounts for the vast majority of the 63 red shards):
darwin agent flakes (each on 1 or 2 darwin aarch64 shards only):
The binary-size annotation reports +0.0 KB on every target, so the compiled output is byte-identical to main, which is expected for a rename-only refactor. This branch does not touch The previous full run on this branch (build 61978) was 285/286 green. This diff is ready for review/merge; the red here is the api.github.com blip plus the usual darwin flakes, and just needs a re-run. |
…zigglobalobject # Conflicts: # src/jsc/bindings/JSFFIFunction.cpp # src/jsc/bindings/v8/shim/FunctionTemplate.cpp
|
Merged current main into the branch again (0cf88d3). Two real conflicts, both from the recent upgrades:
Also caught a fresh Debug build links and |
|
Build 62890 (0cf88d3) did not run: the Buildkite orchestrator returned The diff built and passed tests locally after the merge (see previous comment). This just needs CI to be re-kicked once the build images are available again. |
|
Build 63071 (21ca0a3, after the latest main merge) finished: 285 shards passed, 1 failed. The single failure is Binary-size annotation reports +0.0 KB on every target against main #63069, which is the expected outcome for a rename-only refactor. The diff is ready for review/merge. |
…zigglobalobject # Conflicts: # src/jsc/bindings/BunProcess.cpp # src/jsc/modules/NodeModuleModule.cpp # src/jsc/modules/NodeModuleModule.h
|
Merged current main into the branch again (a7d58a4). Three conflicts, all from #31826 (the node:stream v26.3.0 sync):
Debug build links and |
|
Build 63229 (f28363b, the test-comment fix on top of the a7d58a4 merge) finished: 260 shards passed, 1 failed, 25 canceled. Canceled (25 Windows shards): fleet-wide agent provisioning outage. The Failed (1): The diff remains ready for review; the red here is the Windows agent outage plus a single-shard darwin |
…zigglobalobject # Conflicts: # src/jsc/bindings/NodeDirent.cpp
|
Merged current main into the branch again (ba9836d). One real conflict plus one new-file include to retarget:
|
|
Build 63440 (ba9836d, after the latest main merge) finished: 284 shards passed, 2 failed. Binary-size annotation reports +0.0 KB on every target against main #63422. The two failed shards:
None of these touch the rename surface. The diff is ready for review/merge. |
1 participant
What
De-Zigs the JSC bindings layer, in two mechanical stages. The header carried
// TODO: rename this to BunGlobalObjectsince April 2023 (aeb3bb9); the runtime port made the rest of the Zig-prefixed naming stale too.Stage 1: the global object
Zig::GlobalObjectandZig::EvalGlobalObjectmove tonamespace BunZigGlobalObject.{h,cpp,lut.txt}becomeBunGlobalObject.{h,cpp,lut.txt}Zig__GlobalObject__*->Bun__GlobalObject__*,ZigGlobalObject__*->BunGlobalObject__*,Bun__ZigGlobalObject__uvLoop->Bun__GlobalObject__uvLoopStage 2: the rest of namespace Zig and the Zig-prefixed binding files
namespace Zigis gone; all members (SourceProvider, JSFFIFunction, JSWrappingFunction, CallSite, ImportMetaObject, JSCStackTrace/JSCStackFrame, BunPlugin, string helpers) now live innamespace BunZigSourceProvider.{h,cpp},ZigException.cpp,ZigGeneratedCode.cpp,ZigLazyStaticFunctions{,-inlines}.h->Bun*ZigException,ZigStackTrace,ZigStackFrame,ZigStackFramePosition,ZigStackFrameCode,ZigErrorType,ZigErrorCode->Bun*CommonStringsForZig->CommonStringsForBun(andBun__CommonStringsForZig__toJS->Bun__CommonStringsForBun__toJS)Zig_ErrorCodeParserError/Zig_ErrorCodeJSErrorObject->Bun_*;zig__ModuleInfo*/zig__renderDiff->bun__*bundle-functions.ts,generate-classes.ts,cppbind.tstype maps), build scripts,$newCppFunctionreferences, leaksan suppressions and docs updated to matchRelationship to #30747
#30747 is the full-codebase superset of this rename (same target names) but is currently conflicting and stacked on #30683. This PR lands the bindings-layer portion fresh against main. Still intentionally left for the bigger sweep:
ZigString/ZigStringSliceand friends,ZIG_EXPORT/ZIG_DECL/ZIG_NONNULL,ZigGeneratedClasses(codegen artifact naming), and crate-internalzig_*names.Non-mechanical bits
BunClientData.hforward-declarednamespace Zig { class GlobalObject; }right beforeusing namespace Zig;; both are nowBunclass GlobalObject;insidenamespace Zigblocks; those decls moved tonamespace BununsafeEvalNoopwas defined in bothNodeVM.cppand the formerly-Zig::block of the global object cpp; the latter is nowstaticto avoid a duplicate symbol after the namespace mergedestroy/visitChildrenImplblock inBunGlobalObject.cppis deleted instead of renamed (the live implementations are earlier in the same file), and the stalebun__renderDiffhome-path comment inphase_c_exports.rsnow points at its actual definition insrc/runtime/test_runner/diff_format.rsJSWrappingFunction.cppreferencedBun::NativeFunctionPtrfor a type that then lived innamespace Zig; it only compiled because of unified-build include leakage, now consistentnapi.cppneeded oneJSC::Exceptionqualification that became ambiguous once theusing Exception = JSC::Exceptionalias moved intonamespace BunModuleconstructor inNodeModuleModule.cppcarried a TODO about static_casting the lexical global to the (renamed) class; it now usesdefaultGlobalObject()so non-Bun globals (node:vm) fall back to the main global instead of reading through a bogus pointerVerification
cargo checkpasses on the full workspace; full debug (ASAN) build passesgit grep "Zig::|namespace Zig|ZigGlobalObject|ZigException|ZigSourceProvider"comes back empty (modulo the intentionally-keptZigStringfamily and uncompiled.zigreference files)streams.test.js,shadow.test.js,vm.test.ts,plugins.test.ts,worker_threads.test.ts,node-module-module.test.js,ffi.test.js, plusError.prepareStackTraceCallSite formatting, uncaught-exception rendering, andbun build: all passNo behavior change, so no new test; existing suites cover the renamed paths.