Backport -we4013 to the mswin warnflags for Ruby 3.3#135
Merged
Conversation
Ruby 3.3 predates ruby/ruby 091c7d4a54, which promotes C4013 to an error on mswin. Without it mkmf's have_func probe for a compiler builtin such as __builtin_clzll compiles a bare implicit declaration and reports a false positive, so json's parser selects a symbol that does not exist under MSVC and fails to link, breaking gem install json on the packaged 3.3. Patch only the older trees that lack the flag, mirroring the vcpkg.json override. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR adjusts the Windows (mswin) packaging workflow to ensure Ruby 3.3 builds treat MSVC warning C4013 (implicit function declaration) as an error, preventing mkmf false positives that can lead to json selecting __builtin_clzll and failing to link on MSVC. It also documents the rationale in the repository README alongside the existing Ruby 3.3 vcpkg.json override.
Changes:
- Add a guarded workflow patch that appends
-we4013tosrc/win32/Makefile.subonly when the flag is not already present (no-op for Ruby 3.4+). - Update README documentation to describe the Ruby 3.3
-we4013backport and why it’s needed.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| README.md | Documents the Ruby 3.3-specific -we4013 warnflags backport and its motivation alongside existing mswin packaging details. |
| .github/workflows/mswin-build.yml | Adds a guarded step to patch Ruby 3.3 mswin warnflags to include -we4013 to avoid mkmf/json link failures. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Building the
jsongem against the packaged Ruby 3.3 fails to link withunresolved external symbol __builtin_clzll, which fails the workflow's own extension-build verification. Ruby 3.3 predates ruby/ruby091c7d4a54, which promotes the mswin C4013 warning to an error. Without that,mkmf'shave_funcstyle probe for a compiler builtin compiles a bare implicit declaration and reports a false positive, sojson's parser selects__builtin_clzll, a symbol that does not exist under MSVC, and fails at link time. Ruby 3.4 and later already carry the flag and build fine.This appends
-we4013to the mswin warnflags for the trees that still lack it, mirroring ruby/ruby091c7d4a54and the existingvcpkg.jsonoverride. The step is guarded by agrepso it patches only Ruby 3.3 and no-ops on 3.4 and later. Verified locally by building Ruby 3.3.11 with the flag, which compiles clean, records-we4013in the packagedrbconfig.rb, and then letsgem install jsonsucceed wherechecking for __builtin_clzll()now correctly reportsno.This is a build-side workaround. The proper fix belongs in
json, whose builtin probe should link rather than only compile, and that is being pursued upstream. This override can be dropped once a fixedjsonis widely available.https://bugs.ruby-lang.org/issues/22180
Generated with Claude Code