Thanks again for pointing out that __bf16 is not a portable replacement here.
My standalone WSL reproduction was intended only to isolate the condition observed in the editor integration. Instead of CLion, It reproduced the integration's -imacros input; it was not meant to claim that __BFLT16_DIG__ should be defined for clangd, nor that libstdc++ should support such a configuration. I will treat that integration issue separately. Independently of that configuration issue, there is a library-internal maintainability point. __gnu_cxx::__bfloat16_t is the existing target-correct libstdc++ abstraction for the type of a bfloat16 literal. It is deliberately defined in c++config using __decltype(0.0bf16), rather than assuming that __bf16 has the required meaning on every target. The local __format::__bflt16_t alias represents the same target-dependent type. Obtaining that type again with decltype(0.0bf16) duplicates the type-selection rule in <format>. Referring to the existing __gnu_cxx::__bfloat16_t instead would keep that rule in one place, preserve the target-specific semantics, and keep <format> concerned only with consuming the already-established type. This is not intended as a workaround for an invalid clangd macro environment, and it does not change the fact that c++config itself correctly needs the literal-based definition. The intended benefit is simply to avoid a second, redundant target-dependent type deduction in <format>. Sincerely, Jakit Jakub Jelinek <[email protected]> 于2026年9月7日周一 23:50写道： > > On Mon, Sep 07, 2026 at 11:31:21PM +0800, Jakit Liang wrote: > > I did some additional investigation and can reproduce the parsing > > failure outside CLion, using Debian's standalone clangd 19.1.7 in WSL2. > > > > The important condition is that clangd is given the GCC bfloat16 feature > > macro, as happens in the CLion configuration. The following minimal > > predefines file is sufficient: > > > > ``` > > #define __BFLT16_MANT_DIG__ 8 > > #define __BFLT16_DIG__ 2 > > ``` > > gcc has a few hundreds of predefined macros, each predefined macro > means something, if you incorrectly define any of them, the same or other > programs can misbehave. > There is no point trying to allow incorrectly redefining just one of those > macros. The predefined macros are usually in implementation namespace (or > even mandated by the standard, see the __cpp* macros) and changing them > makes the program invalid. > > > Thus CLion is not required to trigger the parser diagnostic. In CLion, > > the same condition arises because its clangd integration supplies a > > snapshot of the selected GCC 14.2.0 toolchain's predefined macros via > > an `-imacros` file, including `__BFLT16_DIG__=2`. > > Then CLion is broken. > > Jakub >
