-fpermissive error on gcc c++20 when mixing format.h with and without ostream.h in the same compilation unit

[YarikTH]

There is some problem with mixing {fmt} calls with and without included "fmt/ostream.h" in the same compilation unit. Problem is detected only for GCC with c++20 mode, clang works perfectly fine.
Fmt version is both 8.0.1 and trunk.

https://godbolt.org/z/1GsbvYaG4

/// some header file ///
#include <fmt/format.h>

void func() {
    fmt::print( "{}", std::string() );
}

/// some source file ///
#include <fmt/ostream.h>

int main() {
    fmt::print("{}", "");
    return 0;
}

Outputs:

In file included from <source>:9:
/opt/compiler-explorer/libs/fmt/trunk/include/fmt/ostream.h:82:8: error: partial specialization of 'struct fmt::v8::detail::fallback_formatter<T, Char, typename std::enable_if<fmt::v8::detail::is_streamable<T, Char>::value, void>::type>' after instantiation of 'struct fmt::v8::detail::fallback_formatter<std::__cxx11::basic_string<char>, char, void>' [-fpermissive]
   82 | struct fallback_formatter<T, Char, enable_if_t<is_streamable<T, Char>::value>>
      |        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Compiler returned: 1

P.S. minimized version of test code is provided by @alexezeder

[vitaut]

Fixed in e4f0564. Thanks for reporting.

[jdrouhard]

@vitaut

The fix you made for this issue works for std::string and std::string_view, but what about custom types that have both operator<< and a custom formatter defined? We're having this exact same issue with our custom string type, but this fix doesn't help us.

I'd like to be able to disable fmt::detail::is_streamable<> for my custom type without having to include the ostream.h header in the file where we define our custom string class. We only use ostream.h in a few random places but out string class is central and is included everywhere.

Is that possible? I can open a new issue to track, as well, but since it's the same as this one I thought I'd start here.

[vitaut]

@jdrouhard, The current master requires an explicit opt in for ostream which should address your problem: https://fmt.dev/dev/api.html#ostream-api

[jdrouhard]

Yep, that'll do. I look forward to the release with that! Thanks.