Set matching CC alongside CXX in Linux CI matrix

[hexonal]

Fixes #4858

Problem

The Linux CI matrix deliberately varies matrix.cxx across old and new compilers (g++-4.9, clang++-3.6, clang++-20, etc.) to test compatibility, but the Configure step only sets CXX. With no CC, CMake's C compiler detection falls back to whatever default happens to be on the runner (as reported: clang++-3.6 for C++, but GNU 11.4.0 detected for C) — completely unrelated to the compiler version the job is actually meant to be testing.

Fix

Add a small step before Configure that derives CC from the same matrix.cxx value each job already installs a matching compiler for (clang++-N → clang-N, g++-N → gcc-N):

cc=${{matrix.cxx}}
cc=${cc/clang++/clang}
cc=${cc/g++/gcc}
echo "CC=$cc" >> "$GITHUB_ENV"

Testing

This is a CI-config-only change, so the real test is the workflow run itself — I checked every distinct matrix.cxx value used in this file (g++-4.9, g++-11, g++-13, g++-14, clang++-3.6, clang++-11, clang++-14, clang++-20) against the corresponding install/package steps in the same file to confirm a matching gcc-N/clang-N binary is actually installed for each before relying on it (e.g. the "Install GCC 4.9" step explicitly dpkg -is a gcc-4.9 package, "Install Clang 3.6" explicitly installs clang-3.6, etc.) — the two entries without an explicit install step (g++-13/g++-14 on ubuntu-24.04, one clang++-14 variant) rely on the runner image's default toolchain, where the C and C++ drivers for the same version are always installed together. I also verified the string-substitution logic locally in bash against all 8 values (clang++-3.6 correctly does not get double-substituted by the g++→gcc replacement, since the clang++→clang substitution runs first and already consumes the trailing g++ substring), and validated the YAML with ruby -ryaml. I can't run the actual matrix locally, so I'll be watching this PR's own CI run closely.

[hexonal]

The clang++-3.6/g++-4.9 jobs failed on this run, but not because of this PR's change. The actual error in the clang++-3.6 jobs is wget failing to download the old compiler .debs from launchpadlibrarian.net with repeated ERROR 503: Service Unavailable — an external package-mirror outage, unrelated to the CC/CXX selection logic this PR touches (the new "Select matching C compiler" step itself ran fine, correctly resolving CC=gcc-4.9/CC=clang-3.6). The g++-4.9 jobs show as cancelled rather than failed, which is the matrix's default fail-fast behavior kicking in once the clang++-3.6 jobs errored.

I don't have permission to re-run just the failed jobs (not a repo admin) — happy to push an empty commit to retrigger if useful, or this should resolve on its own next time CI runs against this branch.

[vitaut]

I triggered a re-run.

[hexonal]

Thanks for the re-run -- that surfaced something worth flagging.

Good news: the compiler downloads succeeded this time (no more wget 503s), and the new "Select matching C compiler" step resolved CC correctly -- CC=clang-3.6 for the clang job, confirmed by CMake logging "The C compiler identification is Clang 3.6.2". So the actual fix in this PR is working as intended.

But clang++-3.6 c++11 Release now fails for a different, genuine reason: test/c-test.c fails to compile with "too many arguments to function call, expected 0, have 1" on the "foo" string-literal arguments (lines 68 and 93). I traced it to FMT_MAKE_ARG in include/fmt/fmt-c.h, which dispatches on argument type via C11 _Generic and falls back to a 0-arg fmt_unsupported_type() for unmatched types. Clang 3.6's _Generic appears not to apply array-to-pointer decay to the controlling expression, so a "foo" argument (type char[4]) doesn't match the char*/const char* associations and falls into that 0-arg default, which then gets called with (x) anyway -- hence the error.

Importantly, this isn't something this PR's diff introduces (it only touches the workflow file), and it isn't new in the code -- it's a preexisting incompatibility between the C API and real Clang 3.6 that CI never actually caught before, for exactly the reason this PR exists: CC was silently defaulting to the runner's GCC 11, so the C side of the "clang++-3.6" job was never really compiled with clang-3.6. I confirmed this by comparing against today's main run of the same job (identical fmt-c.h/c-test.c -- I diffed them): on main, C still identifies as "GNU 11.4.0" there, and c-test.c compiles and its ctest passes fine under that substituted GCC. So this fix is working correctly; it just uncovered a real, previously-hidden bug.

g++-4.9 got cancelled by fail-fast before reaching this step, so it's still unknown whether it hits the same or a different issue there.

Since fixing fmt-c.h for Clang 3.6 is outside what this PR is meant to do, how would you like to handle it -- a follow-up issue, or would you rather I look at a fix for the _Generic fallback here? Happy to do either.

[vitaut]

how would you like to handle it -- a follow-up issue, or would you rather I look at a fix for the _Generic fallback here?

If there is an easy fix, then I suggest doing it as part of the current PR. Otherwise, we could disable the C test in the problematic config for now.

Thanks for looking into it!

[hexonal]

Dug into this -- root cause is confirmed and it's not a bug in fmt's macro. FMT_MAKE_ARG's _Generic dispatch in fmt-c.h relies on the controlling expression decaying char[N] string literals to char*/const char* before type matching. Whether _Generic's controlling expression decays arrays was genuinely ambiguous in the C11 wording (WG14 N1930) -- GCC always applied the decay, Clang didn't, until the fix for LLVM PR16340 landed in Nov 2015 (clang 3.8). Clang 3.6.2 (Feb 2015) predates that fix by a year, so "foo" never matches char*/const char* and falls through to the 0-arg default, which is then called with an argument -- exactly the reported error.

I looked hard for a macro-level fix and don't think there's a safe one for this PR. The obvious workaround -- forcing decay by wrapping the argument as (x)+0 or 1 ? (x) : (x) -- does force the array decay, but it also triggers ordinary C integer promotion on every small-integer case in the table (char, bool, unsigned char, short, ...), on every compiler, not just old Clang. I verified this concretely: it reroutes a plain char argument to the int case instead of char, which would silently change how the C API formats char/bool/short arguments everywhere, not just paper over Clang 3.6. There's no way to scope the workaround to "just the array case" without already knowing the argument's type at macro-expansion time, which is the very thing _Generic exists to determine, so this really is a compiler bug rather than something fixable in fmt-c.h without a bigger redesign.

Given that, I went with your second option: skipped just the c-test target (via ctest -E ^c-test$) for the clang++-3.6 job, with a comment explaining the LLVM PR16340 history. That job's own C++ tests are untouched and still run -- only the C-API smoke test is skipped, and only for that one legacy compiler.

One thing worth flagging on my own work: my first pass at this had a real bug -- the templated exclude=${{ ... }} value needs to be double-quoted when assigned, since GitHub Actions substitutes it inline and the unquoted form (exclude=-E ^c-test$) doesn't parse as a single shell assignment under bash's default -e mode, it tries to run a nonexistent ^c-test$ command and aborts the step. Caught and fixed that before pushing, and verified both the clang++-3.6 branch and every other matrix entry by actually executing the resulting shell snippet, not just reading it.

Pushed.