This is now merged for trunk and backported to 15/16. Thank you for the patch.
On Wed, Sep 9, 2026 at 12:08 PM Jonathan Wakely <[email protected]> wrote: > On Wed, 9 Sept 2026 at 02:31, Steve Sudit <[email protected]> wrote: > > > > basic_format_parse_context::check_dynamic_spec<_Ts...> checks its > > template arguments with > > > > static_assert(__valid_types_for_check_dynamic_spec<_Ts...>(), ...); > > > > where __valid_types_for_check_dynamic_spec is a non-static consteval > > member, so the operand is an implicit member access on *this evaluated > > directly by the static_assert, not inside a call to a constexpr member > > function. P2280R4 allows that use of this (the function never reads > > through it), and GCC and MSVC accept it, but Clang (through 23 and > > trunk, llvm/llvm-project#191104) and EDG 6.9 still reject the > > instantiation: > > > > error: static assertion expression is not an integral constant > > expression > > note: implicit use of 'this' pointer is only allowed within the > > evaluation of a call to a 'constexpr' member function > > > > so any user formatter that calls check_dynamic_spec<Ts...>(id) fails to > > compile with those front ends in C++26 mode. > > > > The function uses no non-static member, so declaring it static removes > > the this and changes nothing else. std/format/parse_ctx.cc already > > instantiates check_dynamic_spec<Ts...>, which GCC accepts with either > > spelling. > > > > Assisted-by: Claude Fable 5.1 (Anthropic) > > > > libstdc++-v3/ChangeLog: > > > > PR libstdc++/127219 > > * include/std/format > > (basic_format_parse_context::__valid_types_for_check_dynamic_spec): > > Make static, so that the static_assert in check_dynamic_spec does > > not use this. > > > > Signed-off-by: Steven Sudit <[email protected]> > > --- > > The diagnosis was made with the assistance of an LLM (Claude Fable 5.1, > > Anthropic), hence the Assisted-by: tag per > > https://gcc.gnu.org/ai-policy.html. I reviewed the change, ran the > > testing below and take responsibility for it. > > > > Tested x86_64-pc-linux-gnu against trunk r17-3939-g08794c636095: the > > std/format subset of the libstdc++ testsuite at -std=gnu++20, 23 and 26 > > (274 passes, no failures), and clang 23.1 in -std=c++26 mode accepts the > > Bugzilla testcase against the patched header where it rejected the > > unpatched one. > > > > OK for trunk? The same code is on the 15 and 16 branches, so a backport > > after a soak on trunk would be welcome. > > Yes, this is OK, thanks. I'll push it to trunk and queue it for backports. > >
