Skip to content

Avoid clang 21/22 C++26-mode frontend crash in StringLiteral's variadic constructor#688

Open
aruisdante wants to merge 1 commit into
getml:mainfrom
aruisdante:fix/clang-cxx26-stringliteral-crash
Open

Avoid clang 21/22 C++26-mode frontend crash in StringLiteral's variadic constructor#688
aruisdante wants to merge 1 commit into
getml:mainfrom
aruisdante:fix/clang-cxx26-stringliteral-crash

Conversation

@aruisdante

Copy link
Copy Markdown

Problem

Any translation unit that includes reflect-cpp headers fails to compile at -std=c++26 on clang 21.1+, 22.1.x, and current trunk: the compiler itself crashes (SIGSEGV in CheckParameterPacksForExpansion; assertion builds fail with "declaration not instantiated in this scope" in LocalInstantiationScope::findInstantiationOf) while parsing using aliases to Literal<...> / NamedTuple<...> types — e.g. parsing/Parser_duration.hpp and parsing/Parser_result.hpp are the first two headers hit. -std=c++23 and earlier are unaffected.

Root cause is an open clang regression from the CWG2369 reapplication, not a reflect-cpp bug: llvm/llvm-project#198052, reported against reflect-cpp specifically in llvm/llvm-project#205000 (an 11-line minimized reproducer, reduced from rfl::internal::StringLiteral, is attached there). The trigger is StringLiteral's variadic constructor constraining itself with a requires-fold over decltype of its own function parameter pack, alongside the competing const char (&)[N] constructor.

Change

Constrain via template type parameters instead:

template <std::same_as<char>... Chars>
constexpr StringLiteral(const Chars... _chars) : arr_{_chars..., '\0'} {}

Semantically equivalent — each argument must still be exactly char — and it sidesteps the clang bug on every version tested. Since the crash fires at parse time, this one constructor is the only change needed to make the whole library usable at C++26 on affected clangs; it can be reverted freely once fixed clang releases are common.

Testing

Verified with clang 22.1.7 (libc++, -fsyntax-only and full builds): with this change, including rfl/json.hpp/rfl/cbor.hpp compiles cleanly at -std=c++20/23/26, and CBOR + JSON round-trips exercising Literal, Field, TaggedUnion, enums, optionals, and containers pass, including under ASan/UBSan. Please let your CI run the full suite to confirm.

Disclosure

This fix was authored with an AI assistant (Claude Code) and reviewed/submitted by the account owner.

Clang 21.1+, 22.1.x, and current trunk crash (SIGSEGV in
CheckParameterPacksForExpansion; assertion builds fail in
LocalInstantiationScope::findInstantiationOf) when compiling any
translation unit that includes reflect-cpp headers at -std=c++26,
because StringLiteral's variadic constructor constrains itself with a
requires-fold over decltype of its own parameter pack — a pattern that
hits an open clang regression from the CWG2369 reapplication
(llvm/llvm-project#198052; reported against reflect-cpp specifically in
llvm/llvm-project#205000, where a minimized reproducer is attached).

Constraining via template type parameters instead is semantically
equivalent (each argument must still be exactly char) and compiles
cleanly at -std=c++20/23/26 on all clang versions tested, including the
affected ones.

Authored with an AI assistant (Claude Code), reviewed and submitted by
the account owner.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates StringLiteral.hpp to constrain the StringLiteral constructor using template type parameters (std::same_as<char>...) instead of a requires-fold over decltype of the function parameter pack. This change, along with the addition of the <concepts> header, prevents compiler crashes in Clang 21/22 when compiling in C++26 mode. There are no review comments, and I have no additional feedback to provide.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant