[CODER-7777]

Fixes #427

The javascript early-exit checks added in b2e41e8 (parse_number.h, ascii_number.h) use fastfloat_unlikely without the point-of-use clang diagnostic guard that the other
[[unlikely]] sites have (approach chosen in #387, see discussion). So clang in C++11/14/17 mode with
-pedantic warns use of the 'unlikely' attribute is a C++20 extension.

• Wraps both sites with the same guarded #pragma clang diagnostic push/pop already used in parse_number.h and decimal_to_binary.h.
• Keeps the __has_cpp_attribute logic in float_common.h unchanged (unlike Guard [[unlikely]] attribute use with C++20 language check #428).
• Adds a clang-14 CI step compiling fast_float.h with -pedantic-errors -Werror in C++11/14/17/20.

Pragmas only affect diagnostics, so code generation is unchanged and there is no performance claim. Tested with the full test suite under clang 14 (C++11 and C++20, -Werror).

[lemire]

@CODER-7777 I consider that it is a bug in clang and should be reported accordingly.

[jwakely]

They'd close it as a dup of llvm/llvm-project#32865

Edit: actually there was a much more recent one which I can't find right now. But they like how it works anyway

[lemire]

@jwakely Do you have a recommendation?

[jwakely]

As a GCC dev ... stick to GCC? 😉 No serious suggestions, sorry - the ugly pragmas seem like a necessary evil

[CODER-7777]

Thanks both. I checked llvm/llvm-project#32865: Clang decided to keep __has_cpp_attribute as is and instead moved these diagnostics into the separate -Wc++NN-attribute-extensions
groups, so a new report would likely be closed as a duplicate.
Since #387 already settled on the point-of-use pragmas, this PR only adds them to the two sites from b2e41e8 that were missing them, so library users building with -pedantic -Werror in
C++11/14/17 don't break.
The failing Alpine riscv64 job is a network timeout while downloading apk-tools from gitlab.alpinelinux.org, like not related to this change.
Happy to drop the new CI step if you'd prefer to keep the PR to the header change only.

[CODER-7777]

Can you please give me any suggestion @lemire on this failing check? It seems to be an issue of the network ?

[adenzhou1350]

Independent AI-assisted check with Ubuntu Clang 14.0.6 supports 78b6a96: a consumer TU calling from_chars fails on base 0de7a21 at exactly those two [[unlikely]] sites in C++11/14/17 with -Wall -Wextra -pedantic-errors -Werror. Your head passes C++11/14/17/20.

I also applied only the two header hunks to 33785d5; the same four modes pass. A caller's own [[unlikely]] after the include still fails in pre-C++20 modes, so the diagnostic suppression does not leak. The current main's wide-integer rejection also survives in GNU++17.

All 26 expected outcomes matched, including deliberate rejection controls. This was syntax-only compilation of exact header exports, not a full test suite, CI or performance check. No competing patch/PR.