Fairlogger crashes in ROOT Cling with C++23 due to libfmt

[YanzhaoW]

Hi,

I have been experimenting with running FairLogger with C++23. For now, all the ROOT macro can't work due to libfmt used in FairLogger:

/opt/FairSoft/include/fairlogger/Logger.h:245:69: error: call to consteval function 'fmt::fstring<int>::fstring<9UL>' is not a constant expression
    static std::string startColor(Color color) { return fmt::format("\033[01;{}m", static_cast<int>(color)); }
                                                                    ^
note: cast that performs the conversions of a reinterpret_cast is not allowed in a constant expression
/opt/FairSoft/include/fmt/base.h:2736:54: note: in call to 'basic_string_view(&"\033[01;{}m"[0])'
    if (FMT_USE_CONSTEVAL) parse_format_string<char>(s, checker(s, arg_pack()));
                                                     ^
/opt/FairSoft/include/fairlogger/Logger.h:245:69: note: in call to 'fstring<9UL>("\033[01;{}m")'
    static std::string startColor(Color color) { return fmt::format("\033[01;{}m", static_cast<int>(color)); }
                                                                    ^~~~~~~~~~~~~
/opt/FairSoft/include/fairlogger/Logger.h:247:85: error: call to consteval function 'fmt::fstring<int, const std::basic_string<char, std::char_traits<char>, std::allocator<char> > &>::fstring<15UL>' is not a constant expression
    static std::string ColorOut(Color c, const std::string& s) { return fmt::format("\033[01;{}m{}\033[0m", static_cast<int>(c), s); }
                                                                                    ^
note: cast that performs the conversions of a reinterpret_cast is not allowed in a constant expression
/opt/FairSoft/include/fmt/base.h:2736:54: note: in call to 'basic_string_view(&"\033[01;{}m{}\033[0m"[0])'
    if (FMT_USE_CONSTEVAL) parse_format_string<char>(s, checker(s, arg_pack()));
                                                     ^
/opt/FairSoft/include/fairlogger/Logger.h:247:85: note: in call to 'fstring<15UL>("\033[01;{}m{}\033[0m")'
    static std::string ColorOut(Color c, const std::string& s) { return fmt::format("\033[01;{}m{}\033[0m", static_cast<int>(c), s); }

So basically recent version of libfmt introduces the compile-time check of the parameters when consteval (feature in C++23) is available. This works well with C++ compilers, like gcc or clang. But it doesn't work with Cling interpreter.

I have submitted an issue regarding to this problem in ROOT, see this.

Someone pointed out a partial solution, which is put fmt::runtime around the string when CLing is used. So the change would be like:

static std::string ColorOut(Color c, const std::string& s) {
    #ifdef __CINT__
    return fmt::format(fmt::runtime("\033[01;{}m{}\033[0m"), static_cast<int>(c), s); 
    #else
    return fmt::format("\033[01;{}m{}\033[0m", static_cast<int>(c), s); 
    #endif 
}

whereever fmt::format or fmt::print is used.

[dennisklein]

Thank you for the report. Do you know whether the std library <print> has similar issues? The idea was all along to eventually replace fmtlib with the std library once it is ready and capable. I think this could be a good chance to evaluate whether a switch to <print> is already feasible (conditional on C++23 of course). What do you think? (I am not up to date on the print/format library topic)

[YanzhaoW]

For now, I can't use std::println in ROOT macro. I think maybe <print> is not even available at the current clang version that Cling is using. Maybe this will work very shortly in the next ROOT releases.

Generally speaking, moving to std::format and std::print is good decision in my opinion. But this would be a major break on backward compatibility as the old code may have custom data formatter, like we have lots of self-defined formatter in R3BRoot:

template <>
class fmt::formatter<ROOT::Math::XYZVector>
{
  public:
    static constexpr auto parse(format_parse_context& ctx) { return ctx.end(); }
    template <typename FmtContent>
    constexpr auto format(const ROOT::Math::XYZVector& vec, FmtContent& ctn) const
    {
        return fmt::format_to(ctn.out(), "[x: {}, y: {}, z: {}]", vec.X(), vec.Y(), vec.Z());
    }
};

All of them will not compile if standard formatting library is used in LOGP instead. I guess we could have another macro, that utilizes std::format instead of fmt::format. But this also means the transition would require a lot of changes.

My personal preference is just to break the backward compatibility as I believe not many of us are even using custom formatters from libfmt. For those code bases that use custom formatters, a simple change of namespace would be enough to fix the problem.