Link, don't just compile, when probing compiler builtins

[hsbt]

Building the parser C extension against an official Ruby 3.3 mswin binary (x64-mswin64_140) fails at link time with an unresolved __builtin_clzll:

parser.obj : error LNK2019: unresolved external symbol __builtin_clzll referenced in function json_parse_number
parser.so : fatal error LNK1120: 1 unresolved externals

The root cause is in ext/json/ext/parser/extconf.rb. have_builtin_func probes the builtin with try_compile, which only compiles and never links. On MSVC __builtin_clzll does not exist, so int main() { __builtin_clzll(0); return 0; } merely triggers C4013 ('__builtin_clzll' undefined; assuming extern returning int), a warning by default. The compile succeeds, HAVE_BUILTIN___BUILTIN_CLZLL gets defined, and ffc_nlz_int64 in ext/json/ext/vendor/fast_float_parser.h selects the __builtin_clzll branch, which then fails to link.

The fix is to use try_link instead of try_compile in have_builtin_func. On GCC/Clang the builtin is resolved inline with no external symbol, so linking succeeds and the fast path is kept exactly as before. On MSVC there is no such symbol, so linking fails and json correctly falls back. This is the right answer on every toolchain and does not depend on any warning-as-error flag.

Ruby 3.4+ mswin happens to mask this because ruby/ruby 091c7d4a54 promotes C4013 to an error via -we4013, so the old try_compile probe already fails there. Ruby 3.3 mswin (and any config where C4013 stays a warning) still hits the false positive, and json's CI apparently runs a Ruby that already carries -we4013, which is why it slipped through. RubyInstaller (mingw/gcc) is unaffected because gcc really provides the builtin.

Verification, cl.exe on x64-mswin64_140, using the exact probe source:

compile-only (try_compile) exit = 0   # false positive
link        (try_link)     exit = 2   # LNK2019, correct

With the fix, ruby extconf.rb reports checking for __builtin_clzll()... no and the parser builds and links cleanly, with no __builtin_clzll symbol left in parser.obj.

An alternative, or additional belt-and-suspenders guard, would be to gate the __builtin_clzll branch in fast_float_parser.h on defined(__GNUC__) || defined(__clang__). The try_link change alone fully resolves the issue, so I kept the change minimal and did not touch the header. Adding mswin Ruby 3.3 to the CI matrix would catch this class of regression, but I left that as a maintainer call rather than editing CI here.

[Copilot]

Pull request overview

This PR fixes a Windows (mswin/MSVC) build failure for the JSON parser C extension by making the builtin-function probe actually link, preventing a compile-only false positive that later becomes an unresolved external at link time.

Changes:

• Switch the have_builtin_func probe from try_compile to try_link so the check validates linkability on MSVC.
• Ensure HAVE_BUILTIN___BUILTIN_CLZLL is only defined when the builtin is truly usable, allowing correct fallback selection.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[nobu]

Since 13 years ago, Ruby's config.h defines HAVE_BUILTIN___BUILTIN_CLZLL.
Is the check necessary?

[byroot]

Right, let's use HAVE_BUILTIN___BUILTIN_CLZLL

[byroot]

2.21.1 is out with the fix.

[hsbt]

👌 Thanks!