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.
