Compile error: partial specialization of struct fmt::v11::formatter

[std-any-emplace]

Printing a const std::filesystem::path with fileystem, fmt/ostream.h and fmt/std.h included and later including fmt/ranges.h in the same compilation unit causes a strange compile error.

Tested with fmt-11.0.0 and gcc-14.2.

#include <filesystem>
#include <fmt/ostream.h>
#include <fmt/std.h>

void f()
{
    const auto fn = std::filesystem::path{};
    fmt::print("{}", fn);
}

#include <fmt/ranges.h>

https://godbolt.org/z/G5TPbz7o9

[Arghnews]

Are you doing this as part of a unity/jumbo or something like that, is that how this scenario occurs?

I believe this is falling foul of this rule, explained nicely by this SO answer:

If a template, a member template or a member of a class template is explicitly specialized then that specialization shall be declared before the first use of that specialization that would cause an implicit instantiation to take place, in every translation unit in which such a use occurs; no diagnostic is required.

Where here you're instantiating the specialization of the formatter by using it to call print, before the other (partial) specializations of it are declared by including the fmt ranges header

Also notably in a comment on that answer, clang silently happily compiles this while gcc doesn't, hence it only failing on gcc

I'm not an expert on this, but as I see it, unless vitaut wants to provide support for this (possibly via a fmt_fwd type header(s) etc. and I don't know how hard that would be) I don't know of a solution for this, other than avoiding it @std-any-emplace

[vitaut]

This could probably happen if f is in a header.

[std-any-emplace]

Are you doing this as part of a unity/jumbo or something like that, is that how this scenario occurs?

Yes, it did indeed happen during a unity build and it took me a while to figure out what was causing compile failure.

My workaround for the issue was to include all aforementioned headers in all library-using files.

[std-any-emplace]

What I also found interesting is, that the constness of fn is important. A non-const fn does not cause failure.