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 39 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
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
Comment |
|
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.
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. |
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
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.
There was a problem hiding this comment.
No remaining issues from my side — every thread I opened over the review cycle is resolved and the latest merge sweep looks clean. That said, this is a 300-file rename across the core JSC bindings layer (global object, C ABI symbols, namespace merge) with a handful of non-mechanical adjustments, so it warrants a maintainer pass before merge.
Extended reasoning...
Overview
This PR mechanically renames the Zig-prefixed surface of the JSC bindings layer to Bun equivalents: Zig::GlobalObject → Bun::GlobalObject, ZigGlobalObject.{h,cpp,lut.txt} → BunGlobalObject.*, namespace Zig merged into namespace Bun, and the ZigException/ZigStackFrame/ZigStackTrace/ZigSourceProvider family renamed on both the C++ and Rust sides — including the corresponding extern "C" symbol names, codegen templates, build scripts, and docs. It touches 300 files spanning src/jsc/bindings/, src/jsc/*.rs, src/codegen/, the v8 shim, webcore, napi, and node module bindings.
The PR description enumerates a small set of non-mechanical adjustments needed to make the namespace merge link cleanly: unsafeEvalNoop made static to avoid a duplicate symbol, one JSC::Exception qualification in napi.cpp, the Module constructor in NodeModuleModule.cpp switched to defaultGlobalObject(), removal of a long-dead commented block in BunGlobalObject.cpp, and ~20 forward-decl blocks moved between namespaces.
Security risks
None identified. This is a pure identifier/namespace rename. No auth, crypto, permission, or input-validation logic is altered; the crypto and TLS files in the diff only change #include paths and Zig::GlobalObject* → Bun::GlobalObject* type spellings. The C ABI symbol renames are matched on both sides, and the binary-size annotation reports +0.0 KB on every target across multiple builds, which is the expected signature of a no-behavior-change refactor.
Level of scrutiny
This needs human review despite being mechanical. It rewrites the most load-bearing files in the runtime (the global object, module loader, exception path, source provider, and every generated-class/sink template), merges two C++ namespaces, and renames extern "C" symbols that the Rust side links against by exact name. A subtle mismatch — a missed rename on one side of the ABI, an ODR violation from the namespace merge, or an over-eager replace inside a string literal — would be easy to miss in a 300-file diff and could surface only at runtime on a less-exercised path. The author has done a thorough job (repeated git grep verifications, full debug/ASAN builds, targeted smoke tests after each main merge), and CI is green modulo unrelated infra flakes, but the blast radius justifies a maintainer skim of at least the non-mechanical bits and the codegen template changes.
Other factors
Over the PR's ~25-day lifetime I left roughly fifteen inline findings (stale doc references, over-eager comment rewrites, mismatched namespace closers, redundant adjacent namespace Bun blocks, leftover zig/zigGlobal locals, dead .gitattributes entry, and merge-reintroduced Zig:: references). Every one was addressed and resolved by the author, who also proactively swept for the same class beyond the specific sites I named. The current bug-hunting pass on 3ab5bda found nothing new. CodeRabbit's substantive concerns were either addressed or correctly identified as pre-existing behavior out of scope for a rename. The PR overlaps with #30747 (the full-codebase superset rename) by design and intentionally leaves ZigString, ZIG_EXPORT, and ZigGeneratedClasses for that follow-up.
|
All 24 review threads from the automated passes are resolved, and there is nothing further outstanding on this side either. Summarizing the current state for whoever picks this up:
The handful of places where the rename required a judgment call rather than a substitution are called out individually in the description; those are the parts most worth a human look. Ready for a maintainer pass. |
|
Build 66620 has finished: 282 passed, 1 skipped, 4 failed out of 287. None of the four failed lanes comes from this branch; each is below. For context, the previous build of this branch (66368, head 1e988b9) was fully green at 286 of 287 with zero failures, and the only difference between the two heads is the 24 main commits brought in by the latest merge plus two one-token type renames ( 1 and 2. This is an active, branch-independent failure across the whole CI fleet: scanning the 59 most recent Buildkite builds, this exact test is failing on 20 of them, on at least ten different unrelated branches (dgram, buffer, console.table, HTMLRewriter, cookies, fs, and so on), all freshly synced with main. Within this build it passed on every Debian, Ubuntu, and alpine-aarch64 lane and failed only on the two alpine x64 (musl) lanes. Whatever is behind it (a listener-retention regression on main, or a GC-sensitive test that has gone hot), it is a property of current main and is hitting everybody. 3. One crash, in one test, in one of the eight Windows-aarch64 shards; the other seven passed on this build, and all eight passed on the previous build. The test is old (#15565) and has never failed on any of the 59 recent builds I scanned. None of main's last 10 builds contain any 4. The Autobahn WebSocket conformance suite runs in a Docker container whose image is amd64-only, and this shard landed on an ARM Mac agent that cannot run it, so the service coordinator in Nothing on this branch needs to change for any of these. The same failures will appear on main, or on any branch that syncs with it, whenever main's CI exercises the same lanes. I will keep the branch merged with main, and once main is green again this PR will be too. |
Fixes #31233 ### What does this PR do? #32621 removed the Zig sources; the Rust port is the only implementation. The README, the docs site, and a couple of published packages still describe Bun as written in Zig (#31233 reports the README one). This updates them. Nothing in this PR reaches the compiler: it is markdown, mdx, JSDoc, editor config, and a build-script comment. **User-facing** - `README.md`, `docs/index.mdx`, `packages/bun-vscode/README.md`: "It's written in Zig and powered by JavaScriptCore" now says Rust. - `docs/runtime/index.mdx`, `docs/bundler/esbuild.mdx`, `docs/runtime/{shell,redis,json5,yaml,markdown}.mdx`: "written in Zig" and "Zig-based" claims, each checked against the actual implementation (`src/runtime/shell/`, `src/runtime/valkey_jsc/`, `src/parsers/{json5,yaml}.rs`, `src/md/`). - `docs/bundler/css.mdx`: the CSS bundler was described as "a direct Rust → Zig port of LightningCSS", now "a direct port of LightningCSS". - `docs/bundler/html-static.mdx`: "58,000 lines of Zig" becomes "70,000 lines of Rust" (`src/css/**/*.rs` is 71.7k lines today). - `docs/runtime/utils.mdx`: the `Bun.stringWidth` SIMD implementation lives in `src/jsc/bindings/stringWidth.cpp`, so this one says "native code" rather than claiming Rust. - `docs/runtime/ffi.mdx`: the C++ example was compiled with `zig build-lib add.cpp`; it now shows `clang++` for Linux and macOS. The Zig FFI example itself stays, since calling a Zig shared library through `bun:ffi` is unrelated to Bun's implementation language. - `packages/bun-types/bun.d.ts`: the `Bun.password` JSDoc credited the Zig standard library. The implementation routes to the `rust-argon2` and `bcrypt` crates (`src/runtime/crypto/pwhash.rs`), so it now says that. - `LICENSE.md` and `docs/project/license.mdx` still told people to relink WebKit with `git submodule update`, `make jsc`, and `zig build`, none of which exist anymore. The steps now match `docs/project/contributing.mdx`: clone the WebKit fork into `vendor/WebKit`, check out `WEBKIT_VERSION`, run `bun run build:local`. The esbuild credit is now "a port of esbuild". **Developer-facing** - `.vscode/tasks.json`: the "Build Bun" task had a zig-owner problemMatcher for `file:line:col: error:` output. There is no Zig compiler in the build, and the clang matcher next to it handles the same single-line format, so the dead matcher is removed. - `misctools/lldb/README.md`, `scripts/build/deps/nodejs-headers.ts`, `test/js/web/fetch/H2_TEST_PORT_PLAN.md`: internal docs that described `ZigString` as "the Zig string type", a Zig build flag that no longer exists, and a deleted `.zig` path. **Intentionally not changed** - Identifiers that still exist in the code (`Zig::GlobalObject`, `ZigString`, `$ZigGeneratedClasses`, `zig_mutex_t`). #31822 is the rename pass for those. - Comments inside compiled sources (the `src/codegen/*.ts` "written in Zig" docblocks, the `packages/bun-usockets` header, a few `src/js` notes). Those are code changes, not docs, and they fit better with the identifier rename than with this prose pass. - The `bun:ffi` docs listing Zig among the C ABI languages, and the Zig FFI example. - Comments that are deliberately historical: Cargo.toml rationale notes, `bench/snippets/escapeHTML.mjs`, tests that explain a Zig-era bug. - External links into other projects' `.zig` files, such as the Tigerbeetle row in the license table. - `process.versions.zig` is still exposed at runtime with a pinned historical hash (`BunProcess.cpp` and `scripts/build/depVersionsHeader.ts`). Removing a `process.versions` key is a behavior change, not a docs fix, so it is left for a separate decision. ### How did you verify your code works? - This PR changes prose only; no compiled source is touched, so there is no runtime behavior to regression-test. - Every "written in Rust" claim was checked against the implementation it describes before editing (paths above). - `bun test test/integration/bun-types/bun-types.test.ts` passes with the `bun.d.ts` edit. - The docs preview deployment renders the changed pages.
…zigglobalobject # Conflicts: # src/jsc/bindings/bindings.cpp
|
Merged current main into the branch again (86438b9, 31 main commits since the previous sync at f789198). One content conflict, in The post-merge sweep caught one reintroduction that auto-merged without a textual conflict, for the third main merge in a row, and a new shape this time. #32966 ("node:fs: validate open() flag and mode strings like Node") added a new file-scope Verification: the full debug build passes, and On the two open CI failures from the previous build: none of the 31 new main commits touches |
|
Build 67336 (86438b9, the latest main merge) has finished: 282 passed, 1 skipped, 4 failed out of 287. None of the four comes from this branch. Good news first. The Windows aarch64 The four failures:
The binary-size annotation is green (all targets within the 0.50 MB guard), with the usual build-to-build jitter of a few tens of KB in either direction against the moving main canary. Nothing on this branch needs to change and there is nothing left for me to push. Across the last three builds, every red lane has been CI infrastructure, a fleet-wide failure on main, or an intermittent test that also fails on other branches, while this branch's own content has held at 282 to 286 of 287 green throughout. Ready whenever a maintainer is; the remaining red belongs to main. |
…zigglobalobject # Conflicts: # src/codegen/generate-jssink.ts # src/jsc/bindings/BunException.cpp # src/jsc/bindings/BunGlobalObject.cpp # src/jsc/bindings/BunGlobalObject.lut.txt # src/jsc/bindings/JSMockFunction.cpp # src/jsc/bindings/bindings.cpp # src/jsc/bindings/webcore/JSReadableStream.cpp # src/jsc/bindings/webcore/ReadableStream.cpp
|
Merged current main into the branch again (d8386c3, 88 main commits since the previous sync at a50f1f3). This is the largest sync so far, because main landed #33193, the rewrite of ReadableStream, WritableStream, and TransformStream in C++. That rewrite deleted much of the stream bridge code this branch had renamed and added a whole new Conflicts (8). Five were main deleting code that this branch had only renamed, so the resolution is main's deletion with nothing of the rename left to preserve:
Three were real content changes on a line this branch had renamed:
Post-merge sweep reintroductions. All from #33193's new
After all of it, Verification. The full debug build passes. On the open CI failures from the previous build: none of the 88 new main commits touched |
|
Build 69899 (a552c6b, the 88-commit main merge plus autofix-ci's blank-line cleanup) has finished: 285 passed, 1 skipped, 1 failed out of 287. Zero test failures have been recorded on this build; there is no error-level annotation at all. The one failed job is the chronically broken agent This result validates the most consequential merge so far: the rename now covers #33193's new
The binary-size annotation is green: six rows read ±1 to 16 KB against the Nothing on this branch needs to change. If a green check is wanted, retrying the one |
|
Merged current main into the branch again (e82f8fe, 36 main commits since the previous sync at 3f5d816). This one auto-merged with zero conflicts. The post-merge sweep caught a single reintroduction, the smallest yet. #31859 ("socket: hold Bun.listen/Bun.connect callbacks in a GC-visited internal-fields cell") added a new file, Verification: the full debug build passes. |
|
Build 70843 (e82f8fe, the 36-commit clean merge) has finished: 283 passed, 1 skipped, 3 failed out of 287. None of the three comes from this branch, whose only change this merge is one
The rest of the build is green. In particular, Nothing on this branch needs to change. Both database failures are currently hitting everyone who syncs with main, and the Puppeteer browser-launch failure is integration-test infra. Ready for a maintainer. |
…zigglobalobject # Conflicts: # src/jsc/bindings/webcore/streams/JSStreamsRuntime.cpp
|
Merged current main into the branch again (45916a9, 7 main commits since the previous sync at b05b4fa). One content conflict, in The post-merge sweep caught one reintroduction from the same PR: its new file Verification: the full debug build passes, and |
|
Build 71003 (45916a9, the 7-commit merge) has finished: 284 passed, 1 skipped, 2 failed out of 287. Both failures are recurrences of the fleet-wide CI infrastructure issues documented on the previous build:
Every darwin and Windows-aarch64 shard passed, and the Postgres Nothing on this branch needs to change; both red lanes are on everyone currently synced with main. Ready for a maintainer. |
…zigglobalobject # Conflicts: # src/jsc/lib.rs
|
Merged current main into the branch again (a6f714d, 5 main commits since the previous sync at fc865b3). One content conflict, in The post-merge sweep found zero reintroductions, the first time in this PR's history. After the merge, Verification: the full debug build passes, and |
|
Build 71253 (a6f714d, the 5-commit merge) has finished: 285 passed, 1 skipped, 1 failed out of 287. The one failed job is Everything else is green: every darwin-aarch64, Windows-aarch64, alpine, and Nothing on this branch needs to change. Ready for a maintainer. |
…zigglobalobject # Conflicts: # src/bun_bin/phase_c_exports.rs # src/jsc/ErrorCode.rs # src/jsc/Errorable.rs # src/jsc/VirtualMachine.rs # src/jsc/bindings/JSEnvironmentVariableMap.cpp # src/jsc/bindings/JSFFIFunction.cpp # src/jsc/bindings/headers-handwritten.h # src/jsc/bindings/napi.cpp # src/jsc/bindings/napi_handle_scope.cpp # src/jsc/bindings/webcore/Worker.cpp # src/jsc/lib.rs # src/runtime/bake/DevServerSourceProvider.h # src/runtime/ffi_imports.rs
|
Merged current main into the branch again (2a510e7, 118 main commits since the previous sync at 86caf6e). This is the largest conflict count so far, mostly from #31216 (the worker_threads / SHARE_ENV / MessagePort rollup) and the napi hardening work, both of which rewrote sizeable blocks this branch had renamed. Conflicts (13). Two were modify/delete where this branch had only renamed comment text, so main's deletion is taken:
For the eleven content conflicts ( Two of this branch's non-mechanical Stage 2 adjustments sit in files that were overwritten, so they were re-applied explicitly: the Post-merge sweep reintroductions, all from auto-merged files with new main code that did not conflict, and all renamed in the same commit: Verification. The full debug build passes. |
The 2a510e7 merge overwrote VirtualMachine.rs with main's version and re-applied the rename sed. Main's copy of this comment has the pre-existing single-underscore typo ZigGlobalObject__create, so the sed produced BunGlobalObject__create, regressing 50d99c9 which had corrected the comment to name the actual Bun__GlobalObject__create symbol (matching lines 105, 113, 1944, 2137, 2163, 3100 and the definition in BunGlobalObject.cpp). This was the only such occurrence.
|
Build 73209 (c6065fc, the 118-commit main merge plus autofix-ci's rustfmt and the review-fix commit) has finished: 283 passed, 1 skipped, 3 failed out of 287. None of the three comes from this branch.
so Every build lane passed, which validates the 118-commit merge on every platform (including the main-verbatim-plus-rename-sed resolution of Nothing on this branch needs to change. Ready for a maintainer. |
|
Merged current main into the branch again (54db3c3, 16 main commits since the previous sync at aa327ab). This one auto-merged with zero conflicts, and the post-merge sweep found zero reintroductions; both the full pattern set and the Verification: the full debug build passes, and |
|
Build 73556 (54db3c3, the 16-commit clean merge) has finished: 266 passed, 1 skipped, 20 failed out of 287. That is the highest failed-lane count in this PR's history, and every one of them is main-side.
Binary size is green: nine targets at +0.0 KB, three at ±16 KB, three Windows rows within ±4 KB of the Nothing on this branch needs to change. Main is currently broken (the transpiler failure alone takes out a test lane on every platform for every branch synced to it); once that is fixed on main, the next merge here should be green again. |
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 -E "namespace Zig|ZigGlobalObject|ZigException|ZigStackFrame|ZigStackTrace|ZigSourceProvider"comes back empty across the whole repo. Earlier revisions needed a caveat for the uncompiled.zigporting-reference sources, whose comments also matched; Remove the .zig porting-reference sources #32621 removed those from main and this branch has merged it, so the grep is unconditionally clean. The intentionally-keptZigStringfamily is a different name and never matched this pattern. The only hits a plaingit grep "Zig::"still turns up are threeCryptoHasherZig::calls insrc/runtime/crypto/CryptoHasher.rs, a pre-existing Zig-suffixed Rust struct (it names the non-OpenSSL hasher variant) that is identical on main and unrelated to theZigC++ namespace.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.
no test proof · iteration 63 · Platform-specific test(s) that do not run on this machine. Deferring to CI, which covers all platforms: test/js/web/broadcastchannel/broadcast-channel-worker-gc.test.ts test/regression/issue/29519.test.ts test/regression/issue/30205.test.ts