* Set matching CC alongside CXX in Linux CI matrix
The Configure step only set CXX, so CMake's C compiler detection
fell back to whatever the default happened to be on the runner,
independent of which C++ compiler the matrix entry was actually
testing (e.g. CXX=clang++-3.6 but CC left to detect GCC 11).
Derive CC from the same matrix.cxx value the job already installs
a matching compiler for.
* Skip c-test when the C compiler is Clang < 3.8
Setting CC from matrix.cxx means the clang++-3.6 job now configures with real
clang 3.6 instead of falling back to the runner's default GCC, which exposes a
compile failure in test/c-test.c: clang predates the LLVM PR16340 fix (landed in
3.8) that applies array-to-pointer decay to the controlling expression of
_Generic, so fmt-c.h's FMT_MAKE_ARG dispatch never matches a string literal
(char[4]) against its char*/const char* associations. It falls through to the
zero-argument default association, which is then called with one argument.
The guard is at configure time rather than in the CI Test step. c-test is part
of the default target, so `cmake --build` compiles it before ctest ever runs --
excluding it with `ctest -E` cannot help, because the job has already failed in
the Build step. Guarding the add_executable also means anyone building fmt's
tests with an old clang benefits, not just this one CI job.
enable_language(C) stays first and unconditional, since CMAKE_C_COMPILER_VERSION
is not set before it. fmt-c itself (src/fmt-c.cc, C++) still builds on that job;
only the C-consumer smoke test is skipped.
A named argument that arrives const-qualified was not recognized by
is_named_arg, silently dropping its name. This happens both when a
named argument is passed through an intermediate function returning
const T& (https://github.com/fmtlib/fmt/issues/4866) and in fmt's own
compiled format path, which passes arguments as const T&.
Make is_named_arg and is_static_named_arg see through top-level const so
the name is preserved instead of dropped.
The .gitignore-derived `build/` pattern does not actually prune the build
directory or its contents from the CPack source package, so an empty build/
(and, once docs were built in CI, build/doc-html) leaked into the zip. Ignore
the whole build tree in CPACK_SOURCE_IGNORE_FILES.
The source-zip build moved to CI, which configured out-of-source and never
ran the doc target, so the pre-rendered HTML docs (doc-html/) silently
dropped out of the package. Install the doc toolchain, build the docs, and
stage them into the source tree before package_source so CPack picks them up.
The lint workflow was path-filtered to source files, so PRs that didn't
touch them never ran clang-format/cmake-format. Since those checks are
required, such PRs were blocked forever waiting for a status that never
came. Drop the paths filter so the workflow always reports a status.
The provenance job called the SLSA generator with contents: read, but the
generator's upload-assets job declares contents: write. A reusable
workflow's job permissions may not exceed the caller's, so GitHub failed
the run at startup. Grant contents: write; the upload-assets job is still
skipped at runtime since upload-assets is false.
With upload-assets the SLSA generator created and published its own
release (and tag) to host the attestation, duplicating the draft. Disable
upload-assets and add a job that downloads the provenance artifact and
attaches it to the draft alongside the source zip.
Draft releases do not fire the `release: created` event, so the release
workflow never ran and the source zip and SLSA provenance were not
attached to the draft. Trigger the workflow explicitly from release.py
via workflow_dispatch, passing the tag to attach to and the ref to build
from, and resolve the tag/ref in the workflow for both event types.
Match the naming convention used by the other workflows: lowercase,
single-word names that describe what the workflow does rather than the
tool it uses. Also rename the job from Fuzzing to fuzz for consistency.
Adds .github/workflows/release.yml, triggered on `release: created`, which:
- checks out the release's target_commitish,
- builds the source zip via CMake/CPack (`package_source`),
- uploads the zip to the draft release,
- calls slsa-framework/slsa-github-generator to produce a
SLSA v1.0 *.intoto.jsonl provenance file and attach it to the
same draft release.
After CI completes, the draft has both the zip and the provenance attached,
and the maintainer reviews and publishes as before.
Updates support/release.py to stop building and uploading the zip locally;
that work has moved to CI so the SLSA provenance attests to the actual
build environment that produced the artifact, not to a hash observed
after the fact. The script still builds docs locally because the
subsequent mkdocs deploy step depends on them.
- Update g++ module testing to use g++ version 15 instead of 14.
The module support in version 14 isn't very stable and the module
testing was not working due to unresolved locale symbols.
- Update CI for linux and macos to add verbosity so its consistent with
windows.
- Refactor test/CMakeLists.txt to enable testing for modules
- The tests in `module-test.cc` seem to not have been updated in some
time despite changes in the main library.
- Wide String versions of several tests appear to be deprecated so have
been removed.
- Refactored tests related to `fmt::format_args` that now requires lvalue
references as opposed to direct values.
- Remove the none-working code identified in the `module-test.cc` file
while updating.
- This adds a set of CI tests for linux that include compilers that
support modules
- This CI workflow uses ninja as the build system generator
- Can be integrated with the other linux workflow after successful
testing
Co-authored-by: Mathew Benson <mathew@benson.co.ke>
hexonal
Victor Zverovich
dependabot[bot]
Mathew Benson
Mathew Benson
Zephyr Lykos
Victor Zverovich