Don't inject -freflection when building the module, so it isn't forced onto
the module or its importers. Build enum-test unconditionally (it is a no-op
without reflection) and drop the now-unneeded reflection detection. Enable
reflection explicitly in the g++-16 C++26 CI job.
* Format enums annotated with fmt::as_identifiers (requires C++26 reflection)
Format an enum as the identifier of the matching enumerator if the enum is
annotated with fmt::as_identifiers:
enum class [[=fmt::as_identifiers]] color { red, green, blue };
fmt::format("{}", color::green); // "green"
Values that don't match any enumerator are represented as their underlying
value in decimal before applying string formatting.
Identifiers are retrieved via C++26 reflection (P2996) and the annotation
via P3394. FMT_USE_REFLECTION is autodetected and can be overridden by the
user; without reflection the header is empty.
The header is also part of the fmt module, but, unlike with headers, whether
it provides anything is decided when the module is compiled, so the module
build detects reflection and enables it if the configured standard allows.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Look up enum identifiers by index when the values are dense
The formatter for enums annotated with fmt::as_identifiers did a linear
search over all enumerators. Build a table indexed by the distance from
the smallest enumerator value instead, with empty string views in the
holes, which reduces the lookup to a bounds check and one load.
The table is only used if at least 70% of its elements are identifiers,
limiting its size to 10/7 of the number of enumerators. Sparser enums
keep using the linear search. Distances are computed in uint64_t so that
enums with negative values and values spanning the whole range of the
underlying type are handled without overflow.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Suppress -Wsfinae-incomplete in format-test on GCC 16
GCC 16 warns when a type is completed after it failed to be complete in a
SFINAE context. format-test does this deliberately to check that formatting
of incomplete types works, so the warning is a false positive there and
breaks the build with -Werror.
* Test GCC 16 on CI
GCC 16 is the first compiler with C++26 reflection support, which is needed
by fmt/enum.h, so add a job that builds with it in C++26 mode. It comes from
the ubuntu-toolchain-r/test PPA since Ubuntu 24.04 only ships GCC 14.
Also report when reflection is not detected to make it visible that
enum-test was skipped.
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* 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>
