Faster linux zig build #23075
Faster linux zig build #23075
Conversation
WalkthroughAdds a nullable Changes
Possibly related PRs
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✨ Finishing touches🧪 Generate unit tests
🧪 Early access (Sonnet 4.5): enabledWe are currently testing the Sonnet 4.5 model, which is expected to improve code review quality. However, this model may lead to increased noise levels in the review comments. Please disable the early access features if the noise level causes any inconvenience. Note:
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (3)
cmake/targets/BuildBun.cmake (2)
47-54: Make threads configurable and default smartly (optional)You hard-default to 0 and commented out CPU-based default. Consider re-enabling a DEBUG-only CPU count or reading from env (e.g., BUN_LLVM_CODEGEN_THREADS) to simplify local experimentation.
639-639: Pass flag only when meaningful (optional)Avoid emitting -Dllvm_codegen_threads when 0 to keep zig cmdline clean.
- -Dllvm_codegen_threads=${LLVM_ZIG_CODEGEN_THREADS} + $<IF:$<GREATER:${LLVM_ZIG_CODEGEN_THREADS},0>,-Dllvm_codegen_threads=${LLVM_ZIG_CODEGEN_THREADS},>build.zig (1)
273-274: Default mismatch vs CMake (clarify semantics)CMake defaults threads to 0, but here the default is 1. This makes “unspecified” behave differently between CMake and direct zig builds. Either unify to 0 or document 0=single-threaded, >1=sharded.
- .llvm_codegen_threads = b.option(u32, "llvm_codegen_threads", "Number of threads to use for LLVM codegen") orelse 1, + .llvm_codegen_threads = b.option(u32, "llvm_codegen_threads", "Number of threads to use for LLVM codegen (0 = single-threaded)") orelse 0,
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (3)
build.zig(3 hunks)cmake/targets/BuildBun.cmake(3 hunks)cmake/tools/SetupZig.cmake(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.zig
📄 CodeRabbit inference engine (.cursor/rules/javascriptcore-class.mdc)
**/*.zig: Declare the extern C symbol in Zig and export a Zig-friendly alias for use
Wrap the Bun____toJS extern in a Zig method that takes a JSGlobalObject and returns JSC.JSValue
**/*.zig: Format Zig files with zig-format (bun run zig-format)
In Zig, manage memory carefully with allocators and use defer for cleanup
Files:
build.zig
🧠 Learnings (3)
📓 Common learnings
Learnt from: CR
PR: oven-sh/bun#0
File: CLAUDE.md:0-0
Timestamp: 2025-09-08T04:44:59.101Z
Learning: For platform-specific changes, run bun run zig:check-all to compile on all platforms
📚 Learning: 2025-09-08T04:44:59.101Z
Learnt from: CR
PR: oven-sh/bun#0
File: CLAUDE.md:0-0
Timestamp: 2025-09-08T04:44:59.101Z
Learning: For platform-specific changes, run bun run zig:check-all to compile on all platforms
Applied to files:
cmake/tools/SetupZig.cmakebuild.zigcmake/targets/BuildBun.cmake
📚 Learning: 2025-08-30T00:13:36.815Z
Learnt from: CR
PR: oven-sh/bun#0
File: .cursor/rules/zig-javascriptcore-classes.mdc:0-0
Timestamp: 2025-08-30T00:13:36.815Z
Learning: Applies to src/bun.js/bindings/generated_classes_list.zig : Update src/bun.js/bindings/generated_classes_list.zig to include new classes
Applied to files:
cmake/targets/BuildBun.cmake
🔇 Additional comments (2)
cmake/tools/SetupZig.cmake (1)
23-23: Zig commit bump: confirm feature compatibility and cachesPlease confirm this commit includes Compile.no_link_obj and llvm_codegen_threads, since build.zig now guards/uses them. Clear vendor/zig caches in CI to avoid mixing old stdlib with the new compiler.
Based on learnings
build.zig (1)
71-72: New option looks goodField addition is fine and gated usage via @Hasfield elsewhere prevents older Zig breakage.
| if (LLVM_ZIG_CODEGEN_THREADS GREATER 1) | ||
| foreach(i RANGE ${LLVM_ZIG_CODEGEN_THREADS}) | ||
| list(APPEND BUN_ZIG_OUTPUT ${BUILD_PATH}/bun-debug.${i}.o) | ||
| endforeach() | ||
| else() | ||
| set(BUN_ZIG_OUTPUT ${BUILD_PATH}/bun-debug.o) | ||
| endif() |
There was a problem hiding this comment.
Off-by-one when expanding multi-object outputs
foreach(RANGE ${LLVM_ZIG_CODEGEN_THREADS}) yields N+1 entries (0..N). Use 0..(N-1).
Apply:
- if (LLVM_ZIG_CODEGEN_THREADS GREATER 1)
- foreach(i RANGE ${LLVM_ZIG_CODEGEN_THREADS})
- list(APPEND BUN_ZIG_OUTPUT ${BUILD_PATH}/bun-debug.${i}.o)
- endforeach()
+ if (LLVM_ZIG_CODEGEN_THREADS GREATER 1)
+ math(EXPR LLVM_ZIG_CODEGEN_THREADS_LAST "${LLVM_ZIG_CODEGEN_THREADS} - 1")
+ foreach(i RANGE 0 ${LLVM_ZIG_CODEGEN_THREADS_LAST})
+ list(APPEND BUN_ZIG_OUTPUT ${BUILD_PATH}/bun-debug.${i}.o)
+ endforeach()
else()
set(BUN_ZIG_OUTPUT ${BUILD_PATH}/bun-debug.o)
endif()📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if (LLVM_ZIG_CODEGEN_THREADS GREATER 1) | |
| foreach(i RANGE ${LLVM_ZIG_CODEGEN_THREADS}) | |
| list(APPEND BUN_ZIG_OUTPUT ${BUILD_PATH}/bun-debug.${i}.o) | |
| endforeach() | |
| else() | |
| set(BUN_ZIG_OUTPUT ${BUILD_PATH}/bun-debug.o) | |
| endif() | |
| if (LLVM_ZIG_CODEGEN_THREADS GREATER 1) | |
| math(EXPR LLVM_ZIG_CODEGEN_THREADS_LAST "${LLVM_ZIG_CODEGEN_THREADS} - 1") | |
| foreach(i RANGE 0 ${LLVM_ZIG_CODEGEN_THREADS_LAST}) | |
| list(APPEND BUN_ZIG_OUTPUT ${BUILD_PATH}/bun-debug.${i}.o) | |
| endforeach() | |
| else() | |
| set(BUN_ZIG_OUTPUT ${BUILD_PATH}/bun-debug.o) | |
| endif() |
🤖 Prompt for AI Agents
cmake/targets/BuildBun.cmake lines 589-595: the foreach(RANGE
${LLVM_ZIG_CODEGEN_THREADS}) call expands 0..N inclusive causing an off-by-one;
compute LAST = LLVM_ZIG_CODEGEN_THREADS - 1 (use math(EXPR LAST
"${LLVM_ZIG_CODEGEN_THREADS} - 1")) and then loop foreach(i RANGE 0 ${LAST}) to
produce indices 0..(N-1) and append BUILD_PATH/bun-debug.${i}.o; keep the
existing else() branch for the single-output case.
Output name likely mismatches Zig’s installed artifact
zig build obj installs bun-zig.o (see build.zig:addInstallObjectFile("bun-zig", …)). CMake expects bun-debug*.o. Align names or the link/ARTIFACTS tracking will break.
Option A (align to Zig’s installer):
- list(APPEND BUN_ZIG_OUTPUT ${BUILD_PATH}/bun-debug.${i}.o)
+ list(APPEND BUN_ZIG_OUTPUT ${BUILD_PATH}/bun-zig.${i}.o)
...
- set(BUN_ZIG_OUTPUT ${BUILD_PATH}/bun-debug.o)
+ set(BUN_ZIG_OUTPUT ${BUILD_PATH}/bun-zig.o)Option B: change build.zig’s installer to emit bun-debug*.o. Pick one and keep it consistent end-to-end. Please run bun run zig:check-all after changing. Based on learnings
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if (LLVM_ZIG_CODEGEN_THREADS GREATER 1) | |
| foreach(i RANGE ${LLVM_ZIG_CODEGEN_THREADS}) | |
| list(APPEND BUN_ZIG_OUTPUT ${BUILD_PATH}/bun-debug.${i}.o) | |
| endforeach() | |
| else() | |
| set(BUN_ZIG_OUTPUT ${BUILD_PATH}/bun-debug.o) | |
| endif() | |
| if (LLVM_ZIG_CODEGEN_THREADS GREATER 1) | |
| foreach(i RANGE ${LLVM_ZIG_CODEGEN_THREADS}) | |
| list(APPEND BUN_ZIG_OUTPUT ${BUILD_PATH}/bun-zig.${i}.o) | |
| endforeach() | |
| else() | |
| set(BUN_ZIG_OUTPUT ${BUILD_PATH}/bun-zig.o) | |
| endif() |
🤖 Prompt for AI Agents
In cmake/targets/BuildBun.cmake around lines 589-595, CMake is appending
expected Zig output filenames bun-debug(.i).o but Zig’s build.zig installs
bun-zig.o, causing artifact name mismatch; fix by choosing one naming convention
and applying it consistently: either update these CMake BUN_ZIG_OUTPUT entries
to use bun-zig(.i).o to match build.zig, or change build.zig’s
addInstallObjectFile to emit bun-debug(.i).o to match CMake; after changing,
ensure all references (linking, ARTIFACTS lists, install rules) are updated and
run bun run zig:check-all to validate.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
build.zig (1)
71-71: Clarify semantics for llvm_codegen_threads in optionsField type is ?u32 but downstream defaulting to 1 (Line 273) defeats “null => auto” semantics. Recommend letting null propagate so configureObj can use orelse 0 for “auto”.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
build.zig(4 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.zig
📄 CodeRabbit inference engine (.cursor/rules/javascriptcore-class.mdc)
**/*.zig: Declare the extern C symbol in Zig and export a Zig-friendly alias for use
Wrap the Bun____toJS extern in a Zig method that takes a JSGlobalObject and returns JSC.JSValue
**/*.zig: Format Zig files with zig-format (bun run zig-format)
In Zig, manage memory carefully with allocators and use defer for cleanup
Files:
build.zig
🧠 Learnings (2)
📚 Learning: 2025-09-08T04:44:59.101Z
Learnt from: CR
PR: oven-sh/bun#0
File: CLAUDE.md:0-0
Timestamp: 2025-09-08T04:44:59.101Z
Learning: For platform-specific changes, run bun run zig:check-all to compile on all platforms
Applied to files:
build.zig
📚 Learning: 2025-08-30T00:13:36.815Z
Learnt from: CR
PR: oven-sh/bun#0
File: .cursor/rules/zig-javascriptcore-classes.mdc:0-0
Timestamp: 2025-08-30T00:13:36.815Z
Learning: Applies to src/bun.js/bindings/generated_classes_list.zig : Update src/bun.js/bindings/generated_classes_list.zig to include new classes
Applied to files:
build.zig
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Format
🔇 Additional comments (3)
build.zig (3)
610-616: Compile break: obj.no_link_obj is not a field on Zig 0.14 Compile (and llvm_codegen_threads likely isn’t either)Unconditional
obj.no_link_obj = true;will fail on Zig 0.14. The guardedllvm_codegen_threadsis fine, butno_link_objmust be removed or gated; also consider removing the whole block since these fields aren’t part of 0.14’s public API.Apply this minimal, safe fix:
- if (opts.optimize == .Debug) { - if (@hasField(std.meta.Child(@TypeOf(obj)), "llvm_codegen_threads")) - obj.llvm_codegen_threads = opts.llvm_codegen_threads orelse 0; - } - - obj.no_link_obj = true; + if (opts.optimize == .Debug) { + if (@hasField(std.meta.Child(@TypeOf(obj)), "llvm_codegen_threads")) { + obj.llvm_codegen_threads = opts.llvm_codegen_threads orelse 0; // 0 => auto + } + } + if (@hasField(std.meta.Child(@TypeOf(obj)), "no_link_obj")) { + obj.no_link_obj = true; + }Alternatively, if you don’t plan to target a Zig with these fields soon, delete both assignments entirely.
#!/bin/bash # Prove the fix compiles across targets bun run zig:check-allBased on learnings
677-678: Restore platform-specific extensions for object files
Object files are currently installed without an extension, which can break downstream tooling (e.g., CMake scripts expecting “.o”/“.obj”). In addInstallObjectFile (build.zig:677–678), change the fmt call to include the correct suffix:if (target.os.tag == .windows) ".obj" else ".o"after the basename.
273-274: Default llvm_codegen_threads to nullRemove the
orelse 1fallback soopts.llvm_codegen_threadsremainsnullwhen unset, allowingconfigureObj’sorelse 0to trigger “auto” threading:- .llvm_codegen_threads = b.option(u32, "llvm_codegen_threads", "Number of threads to use for LLVM codegen") orelse 1, + .llvm_codegen_threads = b.option(u32, "llvm_codegen_threads", "Number of threads to use for LLVM codegen"),Run your Zig build tests (e.g.
zig build test) to verify no regressions.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
build.zig (3)
71-71: Add documentation forllvm_codegen_threadsfield.The new field lacks a doc comment explaining its purpose, valid values, and the semantics of
nullvs0vs positive integers. This would help maintainers understand when and how to use this option.Consider adding a comment like:
+ /// Number of LLVM codegen threads. null or 0 = single-threaded, 1+ = parallel. + /// Only applies in Debug builds when the Zig compiler supports it. llvm_codegen_threads: ?u32 = null,
273-273: Clarify default value semantics and improve option description.The default value of
1forllvm_codegen_threadsis unusual—typically threading options default to0(disabled/single-threaded) or auto-detect the CPU count. Verify whether1means "single worker thread" (effectively 2 threads total) or "single-threaded mode."Additionally, the option description is empty. Consider improving it:
- .llvm_codegen_threads = b.option(u32, "llvm_codegen_threads", "Number of threads to use for LLVM codegen") orelse 1, + .llvm_codegen_threads = b.option(u32, "llvm_codegen_threads", "Number of LLVM codegen worker threads (0=single-threaded, 1+=parallel)") orelse 1,
610-613: Drop the unnecessary@hasFieldguard forllvm_codegen_threads
The pinned Zig commit71b7bdb81e4807578911ebeaee3c0e8d292e3724defines bothllvm_codegen_threadsandno_link_obj, so the@hasFieldcheck can be removed to match the unconditionalobj.no_link_objassignment.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
build.zig(3 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.zig
📄 CodeRabbit inference engine (.cursor/rules/javascriptcore-class.mdc)
**/*.zig: Declare the extern C symbol in Zig and export a Zig-friendly alias for use
Wrap the Bun____toJS extern in a Zig method that takes a JSGlobalObject and returns JSC.JSValue
**/*.zig: Format Zig files with zig-format (bun run zig-format)
In Zig, manage memory carefully with allocators and use defer for cleanup
Files:
build.zig
🧠 Learnings (2)
📓 Common learnings
Learnt from: CR
PR: oven-sh/bun#0
File: CLAUDE.md:0-0
Timestamp: 2025-09-08T04:44:59.101Z
Learning: For platform-specific changes, run bun run zig:check-all to compile on all platforms
📚 Learning: 2025-09-08T04:44:59.101Z
Learnt from: CR
PR: oven-sh/bun#0
File: CLAUDE.md:0-0
Timestamp: 2025-09-08T04:44:59.101Z
Learning: For platform-specific changes, run bun run zig:check-all to compile on all platforms
Applied to files:
build.zig
🔇 Additional comments (4)
build.zig (4)
615-615: Consider gatingno_link_objwith@hasFieldcheck for consistency.Line 615 unconditionally sets
obj.no_link_obj = true, while line 611 gatesllvm_codegen_threadswith@hasField. Ifno_link_objalso doesn't exist in certain Zig versions (as past review comments suggested), this will cause a compilation error.Apply this diff to add consistency:
- obj.no_link_obj = true; + if (@hasField(std.meta.Child(@TypeOf(obj)), "no_link_obj")) + obj.no_link_obj = true;Alternatively, if the Zig version is now guaranteed to have both fields, remove all
@hasFieldchecks for clarity:- if (opts.optimize == .Debug) { - if (@hasField(std.meta.Child(@TypeOf(obj)), "llvm_codegen_threads")) - obj.llvm_codegen_threads = opts.llvm_codegen_threads orelse 0; - } - - obj.no_link_obj = true; + if (opts.optimize == .Debug) { + obj.llvm_codegen_threads = opts.llvm_codegen_threads orelse 0; + } + obj.no_link_obj = true;
610-613: Debug-only parallel codegen is a reasonable optimization.Limiting
llvm_codegen_threadsto Debug builds makes sense for faster iteration during development. Release builds likely benefit more from other optimization strategies.
273-273: Align default LLVM codegen thread counts between CMake and Zig build
CMake setsLLVM_ZIG_CODEGEN_THREADSto0by default (cmake/targets/BuildBun.cmake:47), but in build.zig the fallback is1(build.zig:273). Either synchronize these defaults or document the reason for their divergence.
610-616: Verify build changes on all platforms. The modifications toconfigureObjaffect every supported target. Runbun run zig:check-all(or trigger the equivalent CI job) locally to compile for all platforms and confirm thatno_link_objandllvm_codegen_threadsbehave correctly across environments.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
cmake/tools/SetupZig.cmake(1 hunks)
cmake/tools/SetupZig.cmake
Outdated
| endif() | ||
|
|
||
| set(ZIG_COMMIT "e0b7c318f318196c5f81fdf3423816a7b5bb3112") | ||
| set(ZIG_COMMIT "9853cc36e73702ad4032dcaceb22e53db9a039f2") |
There was a problem hiding this comment.
🧩 Analysis chain
Verify the Zig commit hash and its compatibility with the new threading feature.
Given the widespread build failures reported in the PR (affecting macOS, Linux, and Windows builds), this Zig compiler version bump should be verified for:
- Accessibility of the commit in the Zig repository
- Support for the new
llvm_codegen_threadsoption introduced in other files - Any known regressions or compatibility issues
Run the following script to verify the Zig commit:
Additionally, search for documentation on the llvm_codegen_threads feature:
🏁 Script executed:
#!/bin/bash
# Verify the new Zig commit exists and check for recent issues
# Check if the commit exists in the Zig repository
echo "=== Checking Zig commit existence ==="
git ls-remote https://github.com/ziglang/zig.git 9853cc36e73702ad4032dcaceb22e53db9a039f2
# Get commit details
echo -e "\n=== Fetching commit details ==="
gh api repos/ziglang/zig/commits/9853cc36e73702ad4032dcaceb22e53db9a039f2 --jq '{sha: .sha, date: .commit.committer.date, message: .commit.message}'
# Check for any related issues or discussions about this commit
echo -e "\n=== Searching for issues mentioning this commit ==="
gh search issues --repo ziglang/zig "9853cc36e73702ad4032dcaceb22e53db9a039f2" --limit 5 --json title,url,stateLength of output: 573
🌐 Web query:
Zig compiler llvm_codegen_threads option support
💡 Result:
Short answer: No — Zig does not currently provide a supported way to set LLVM's codegen/parallel-codegen threads for Zig codegen (there’s no exposed llvm_codegen_threads / -mllvm pass-through for Zig-language compilation). See the open GitHub issue requesting the ability to pass LLVM-specific flags from build.zig and related discussion. [1][2]
Sources:
- Zig issue tracking request to pass compiler/LLVM flags from build.zig (react production bundle includes more module wrappers than necessary #12726). [1]
- Zig forum/devlog discussion noting limits of the LLVM backend and that some LLVM-only flags are only available via zig cc (C/C++) or not exposed for Zig codegen. [2]
Remove or guard llvm_codegen_threads option until upstream support
Verified commit 9853cc36e73702ad4032dcaceb22e53db9a039f2 exists (Sep 30 2025) but Zig does not expose an llvm_codegen_threads flag for Zig codegen (see issue #12726), so this option will be a no-op.
🤖 Prompt for AI Agents
In cmake/tools/SetupZig.cmake around line 23, the repo pins Zig to commit
9853cc36e73702ad4032dcaceb22e53db9a039f2 but the CMake option or use of
llvm_codegen_threads is unsupported by upstream Zig (no zig codegen flag), so
remove any configuration that sets or passes llvm_codegen_threads, or wrap its
creation/use with a feature check: either delete the option and related logic
entirely or gate it behind a version/commit or feature-detection test (query the
Zig binary or commit/semver before adding the option) so the option is a no-op
until upstream adds support.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
cmake/tools/SetupZig.cmake(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Format
| endif() | ||
|
|
||
| set(ZIG_COMMIT "e0b7c318f318196c5f81fdf3423816a7b5bb3112") | ||
| set(ZIG_COMMIT "55fdbfa0c86be86b68d43a4ba761e6909eb0d7b2") |
There was a problem hiding this comment.
🧩 Analysis chain
Verify the new Zig commit and its relationship to build failures.
The commit hash change occurs alongside widespread build failures across macOS, Linux, and Windows reported in the PR. Additionally, a previous review flagged that Zig doesn't expose llvm_codegen_threads for Zig codegen (see Zig issue #12726), yet this PR introduces that option.
Run the following script to verify the commit exists and check for any related issues:
Additionally, search for the latest status on Zig's LLVM codegen threading support:
🏁 Script executed:
#!/bin/bash
# Verify the new Zig commit exists and gather details
echo "=== Checking if Zig commit exists ==="
git ls-remote https://github.com/ziglang/zig.git 55fdbfa0c86be86b68d43a4ba761e6909eb0d7b2
echo -e "\n=== Fetching commit details ==="
gh api repos/ziglang/zig/commits/55fdbfa0c86be86b68d43a4ba761e6909eb0d7b2 --jq '{sha: .sha, date: .commit.committer.date, message: .commit.message, author: .commit.author.name}' 2>/dev/null || echo "Commit not found or API error"
echo -e "\n=== Searching for issues mentioning this commit ==="
gh search issues --repo ziglang/zig "55fdbfa0c86be86b68d43a4ba761e6909eb0d7b2" --limit 5 --json title,url,state 2>/dev/null || echo "No issues found"
echo -e "\n=== Checking recent Zig issues related to LLVM codegen ==="
gh search issues --repo ziglang/zig "llvm codegen threads OR llvm_codegen_threads" --limit 5 --json title,url,state,createdAtLength of output: 627
🌐 Web query:
Zig commit 55fdbfa0c86be86b68d43a4ba761e6909eb0d7b2 llvm_codegen_threads support
💡 Result:
Do you want me to locate and summarize that specific commit (55fdbfa...) on the Zig repository and explain how it added/changed llvm_codegen_threads support? If so I’ll fetch the commit and report the diff and implications.
Zig commit bump valid but doesn’t add LLVM codegen threading support
Commit 55fdbfa0c86be86b68d43a4ba761e6909eb0d7b2 exists and fixes MachO --no-link, but upstream Zig still lacks llvm_codegen_threads. Remove or guard the threading flag to restore successful builds on macOS, Linux, and Windows.
🤖 Prompt for AI Agents
In cmake/tools/SetupZig.cmake around line 23, the updated Zig commit is fine but
the build is adding an llvm_codegen_threads flag that upstream Zig doesn't
support yet; remove or guard usage of the threading flag to prevent build
failures. Edit the CMake logic that passes flags to Zig so it no longer
unconditionally adds llvm_codegen_threads — either remove that flag entirely or
wrap it in a conditional that checks the target platform/version (e.g., only
enable for environments where Zig exposes llvm_codegen_threads) or probe the Zig
binary for support before adding the flag; update comments and keep the commit
bump intact.
What does this PR do?
How did you verify your code works?