[PATCH] libstdc++: Make __valid_types_for_check_dynamic_spec static [PR127219]

[Jonathan Wakely]

On Wed, 9 Sept 2026 at 02:31, Steve Sudit <stevensudit@gmail.com> 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 <stevensudit@gmail.com>
> ---
> 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.