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

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.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Author: dscho

config.mak.uname

@@ -162,6 +162,17 @@ ifeq ($(uname_S),Darwin)
 		NEEDS_GOOD_LIBICONV = UnfortunatelyYes
         endif
 
+	# Homebrew's LLVM clang ships a regex.h that lacks REG_ENHANCED,
+	# which is needed for USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS above.
+	# Use our bundled regex instead.  This became a practical problem
+	# when Homebrew 5.1.0 started auto-linking versioned keg-only
+	# formulae (like llvm@15) into $(HOMEBREW_PREFIX)/bin/, causing
+	# CC=clang in CI to silently pick up Homebrew's clang instead of
+	# Apple's /usr/bin/clang.
+	ifeq ($(CC),clang)
+		NO_REGEX = HomebrewsClangUsesARegexThatLacksREG_ENHANCED
+	endif
+
 	# The builtin FSMonitor on MacOS builds upon Simple-IPC.  Both require
 	# Unix domain sockets and PThreads.
         ifndef NO_PTHREADS