osx-clang: work around Homebrew's clang lacking REG_ENHANCED

[dscho]

The osx-clang and osx-reftable CI jobs on macOS started failing with:

compat/regcomp_enhanced.c:7:13: error: use of undeclared identifier
'REG_ENHANCED'

The failure coincides with the GitHub Actions macos-14-arm64 runner image being updated from 20260302.0147 to 20260317.0174. The key change in that image update is the Homebrew version bump from 5.0.15 to 5.1.0.

Homebrew 5.1.0 introduced automatic linking for versioned keg-only formulae when the unversioned sibling is absent (see Homebrew/brew#21676, announced at https://brew.sh/2026/03/10/homebrew-5.1.0/). The runner image installs llvm@15 (keg-only) but not unversioned llvm. Under Homebrew 5.0.x that formula stayed in its keg and its clang binary only lived at $(brew --prefix llvm@15)/bin/clang. Under 5.1.0, because unversioned llvm is absent, llvm@15 is now auto-linked into /opt/homebrew/bin/, which sits earlier in PATH than /usr/bin.

The net effect is that CC=clang in CI now silently resolves to Homebrew's LLVM 15.0.7 clang instead of Apple's system clang (Apple clang 15.0.0, bundled with Xcode 15.4). The runner image README confirms this: the reported "Clang/LLVM" version flipped from 15.0.0 to 15.0.7 between image releases, matching the Homebrew LLVM version exactly.

Homebrew's LLVM clang uses different include paths from Apple's clang. In particular, the regex.h it sees does not define REG_ENHANCED, which is an Apple-specific extension present in the macOS SDK headers since at least macOS 10.12. The Makefile unconditionally sets USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS for all Darwin builds via config.mak.uname, which pulls in compat/regcomp_enhanced.c, which references REG_ENHANCED, hence the build failure.

The osx-gcc job (CC=gcc-13) is unaffected because Homebrew GCC is configured to use Apple's SDK sysroot, so it still picks up Apple's regex.h which defines REG_ENHANCED. The osx-meson job is unaffected because Meson does a compile-time test for REG_ENHANCED (via compiler.get_define) and simply skips the feature when it is absent.

Work around this by setting NO_REGEX when CC=clang on Darwin, which makes the build use Git's bundled regex implementation instead of the system one. This sidesteps the missing REG_ENHANCED define entirely.

This corresponds to https://lore.kernel.org/git/d340af9e-334c-4e81-e58a-fc3dea73ebdd@gmx.de/, which I proposed to upstream. Historically, upstream's process is not amenable to quick fixes like that, and besides, we'd have to wait to get the fix until the next Git release, which is due April 20th, and I'm not willing to wait that long.