Format-related string fixes and refactorings

[asl]

• Switch to abseil format routines in places where printf-format strings were used
• Format strings are now checked statically, this uncovered several issues with them
• Util::printf_format is often misused, error prone, redundant and therefore fully eliminated: one needs to use absl::StrFormat and then do explicit cstring conversion if necessary
• Switched SourceCodeBuilder to use cord data structure from abseil
• Some cstring-related refactoring in SourceCode in order to reduce cstrings for transient stuff

Fixes #4689

[asl]

I can probably factor our removal of Utils::printf_format into a separate PR, so it will be a dedicated single entry in the changelog?

[fruffy]

How easy is it to switch from absl::StrFormat to std::format btw? Something worth keeping in mind is that with C++20 we may use more standard library functions instead.

[asl]

How easy is it to switch from absl::StrFormat to std::format btw? Something worth keeping in mind is that with C++20 we may use more standard library functions instead.

Format strings are mess :( abseil uses POSIX (printf-style) format strings with few extensions (so we cannot easily switch from boost::format to it). std::format format strings are python'ish. So, they are all incompatible... Essentially, std::format with plain placeholders is much closer to abseil:StrSubsitute, however, latter does not support any formatting at all, just stringification.

But so far:

• We do use printf-like formats inside parser (due to bison / yacc wanting them) and for SourceCodeBuilder
• boost::format for error messages

[fruffy]

How easy is it to switch from absl::StrFormat to std::format btw? Something worth keeping in mind is that with C++20 we may use more standard library functions instead.

Format strings are mess :( abseil uses POSIX (printf-style) format strings with few extensions (so we cannot easily switch from boost::format to it). std::format format strings are python'ish. So, they are all incompatible... Essentially, std::format with plain placeholders is much closer to abseil:StrSubsitute, however, latter does not support any formatting at all, just stringification.

But so far:

* We do use printf-like formats inside parser (due to bison / yacc wanting them) and for `SourceCodeBuilder`

* boost::format for error messages

But switching from absl::StrFormat to std::format would be easier? As long as we are assured at that we could remove Util::printf_format. Otherwise, we might preserve it to preserve some API compatibility between the different formatting back ends.

[asl]

But switching from absl::StrFormat to std::format would be easier?

I am afraid we'd need to keep printf-formatting for quite some time. Putting backends aside that use this, printf-formatting is used in parser that is autogenerated by Bison and is not ready for anything else :)

[fruffy]

I am afraid we'd need to keep printf-formatting for quite some time. Putting backends aside that use this, printf-formatting is used in parser that is autogenerated by Bison and is not ready for anything else :)

Oh I am not concerned about printf in particular. More about switching from custom formatters (boost, absl) to the stdlib.

[asl]

Oh I am not concerned about printf in particular. More about switching from custom formatters (boost, absl) to the stdlib.

I think it is easier to switch from abseil as it is "semantical" formatting by default. E.g. one specifies "%d" and we'd just need to replace it with {:d} for std::format with some regexp or so. And everything more complicated could be resolved manually. Boost is positional by default, so one cannot just replace stuff with placeholders. Or the latter must be more complicated to be positional as well.

[fruffy]

I think this is fine, we should replace absl::StrFormat with std::format once we have it available.

[fruffy]

What are the changes?

[asl]

Ah, well, there is some logic there, but essentially the format string is chosen programmatically. And we need it constexpr here.