Open Bug 1717448 Opened 3 years ago Updated 2 years ago

Integrate and support {fmt} for c++20 std::format-style formatting in gecko

Categories

(Core :: XPCOM, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: nika, Assigned: nika)

References

Details

In C++20, a new formatting library was defined which uses rust/python style {} format indicators for formatting strings etc. std::format also supports formatting custom types in various manners and will be expanded on in future c++ versions.

In general, gecko has continued to use printf-style formatting over stream style formatting for various reasons, including code size and style. This new format string type has improved flexibility and type safety like operator<< stream formatting, while also being performant and codesize efficient like printf.

While we cannot directly adapt c++20's implementation, as we are still using c++17 and no standard library supports the full spec yet, there is a community implementation of the syntax in the {fmt} library, which also provides extra flexibility allowing us to integrate into ns[C]String more efficiently.

This bug tracks potentially vendoring {fmt} into the tree and adding basic support to core xpcom features like MOZ_LOG and ns[C]String for the library.

One thing to look out for: how it formats floats (specifically, the rounding for floats)

(In reply to Mike Hommey [:glandium] from comment #1)

One thing to look out for: how it formats floats (specifically, the rounding for floats)

I looked into this a while back, and the {fmt} library appears to take glibc's approach to float rounding rather than our approach with double-conversion and ecmascript rules (from that testing I also noticed that their printf implementation appears to have some issues around padding/sign digits, however it's unclear whether this impacts their normal format strings).

If we import the crate, we'll probably want to apply some patches on the source to replace the floating point formatting infrastructure with our existing infrastructure in order to use the ecmascript rules and double-conversion under the hood, as it seems somewhat unlikely to me that they'd be interested in upstreaming ecmascript rounding support.

Depends on: C++20

This proposal uses an third-party library, rather than c++20's format implementation, so doesn't depend on c++20.

No longer depends on: C++20
You need to log in before you can comment on or make changes to this bug.