Add support for built-in int128 when available

[denizevrenci]

I agree that my contributions are licensed under the {fmt} license, and agree to future changes to the licensing.

This is an initial implementation. I want to hear opinions before trying to extend it to other platforms and adding tests for it.

[vitaut]

Thanks for the PR! In general looks good, but I have a bunch of inline comments about the details.

[denizevrenci]

Behavior of std::is_integral is different between libstdc++ with and without GNU extensions, and libc++. I do not want to add specializations to std namespace so I think it is appropriate to have a separate one in the fmt::internal namespace.

I suggest changing the existing functions' name to is_integral_type and is_arithmetic_type to reserve the names of the standard type traits classes.

I noticed that std::is_integral is used in printf.h as well. I suppose at least some of those usages have to be replaced with fmt::internal::is_integral.

Let me know your thoughts.

[vitaut]

Not sure how you'd do that. The other block is inside the union.
Do you mean like this?

Nevermind, I forgot that you need to terminate the union which makes merging the ifdefs awkward. Let's keep as is.

Behavior of std::is_integral is different between libstdc++ with and without GNU extensions, and libc++. I do not want to add specializations to std namespace so I think it is appropriate to have a separate one in the fmt::internal namespace.

Makes sense.

I suggest changing the existing functions' name to is_integral_type and is_arithmetic_type to reserve the names of the standard type traits classes.

Sure. So internal::is_integral will become internal::is_integral_type and internal::is_integral_s will become internal::is_integral?

I noticed that std::is_integral is used in printf.h as well. I suppose at least some of those usages have to be replaced with fmt::internal::is_integral.

I don't think printf supports int128_t (at least not portably) so we don't need to change fmt's implementation either because it's mostly for migrating legacy code.

[denizevrenci]

Okay, the warning is on __int128 which is what I used in this PR, not __int128_t.
https://godbolt.org/z/WYAi6I

Looks like __int128_t is aliased to __int128 and __uint128_t is aliased to unsigned __int128. Using those aliases, we can avoid warning suppression.

[vitaut]

One more thing: please add a test that checks if format works with int128_t somewhere around

fmt/test/format-test.cc

Line 1336 in a128b5b

TEST(FormatterTest, FormatDec) {

.

[vitaut]

Merged, thanks!

[denizevrenci]

Thank you for reviewing and accepting the PR.