Spurious compilation error using <format> and import std

[kamrann]

This issue has been plaguing me for a while, I've finally managed to reduce it somewhat - not minimal, but the only dependency now is libcxx.

This is perhaps related to the known limitation of #include/import ordering with std, but it's a bit different; it requires both import std and #include <format> to repro, but it shows up even with the #include encapsulated into a module, and regardless of the import order in the consuming translation unit.

Compiler Explorer link.

Reproducing for me on both latest trunk and latest release.

// mod_a.cppm
export module mod_a;

import std;

auto something() -> void
{
    auto const buf = "a";
    auto x = std::format("{}", buf[0]);
}

// mod_b.cppm
module;

#include <format>

export module mod_b;

// source.cpp
import std;

// note: import order not relevant
import mod_a;
import mod_b;

auto func() -> void
{
    auto const buf = "a";
    auto x = std::format("{}", buf[0]);
}

auto dies() -> void
{
    std::string_view weird;
    auto x = std::format("{}", weird);
}

Output:

In module 'std' imported from /app/source.cpp:2:
/opt/compiler-explorer/clang-trunk-20250717/bin/../include/c++/v1/__format/format_functions.h:99:30: error: call to implicitly-deleted default constructor of 'formatter<std::__1::basic_string_view<char, std::__1::char_traits<char>>, wchar_t>'
   99 |       formatter<_Tp, _CharT> __f;
      |                              ^
/opt/compiler-explorer/clang-trunk-20250717/bin/../include/c++/v1/__format/format_functions.h:98:62: note: while substituting into a lambda expression here
   98 |     __parse_ = [](basic_format_parse_context<_CharT>& __ctx) {
      |                                                              ^
/opt/compiler-explorer/clang-trunk-20250717/bin/../include/c++/v1/__format/format_functions.h:393:25: note: in instantiation of function template specialization 'std::__format::__compile_time_handle<wchar_t>::__enable<std::__1::basic_string_view<char>>' requested here
  393 |       __handle.template __enable<_Tp>();
      |                         ^
/opt/compiler-explorer/clang-trunk-20250717/bin/../include/c++/v1/__format/format_functions.h:389:99: note: while substituting into a lambda expression here
  389 |   static constexpr array<__format::__compile_time_handle<_CharT>, sizeof...(_Args)> __handles_{[] {
      |                                                                                                   ^
source.cpp:16:26: note: in instantiation of template class 'std::__1::basic_format_string<wchar_t, std::__1::basic_string_view<char> &>' requested here
   16 |     auto x = std::format("{}", weird);
      |                          ^
/opt/compiler-explorer/clang-trunk-20250717/bin/../include/c++/v1/__format/formatter_string.h:141:63: note: default constructor of 'formatter<std::__1::basic_string_view<char>, wchar_t>' is implicitly deleted because base class '__disabled_formatter' has a deleted default constructor
  141 | struct formatter<basic_string_view<char, _Traits>, wchar_t> : __disabled_formatter {};
      |                                                               ^
/opt/compiler-explorer/clang-trunk-20250717/bin/../include/c++/v1/__format/formatter.h:25:3: note: '__disabled_formatter' has been explicitly marked deleted here
   25 |   __disabled_formatter()                                       = delete;
      |   ^

Note the bizarre reference to wchar_t.

[llvmbot]

@llvm/issue-subscribers-clang-modules

Author: Cameron Angus (kamrann)

This issue has been plaguing me for a while, I've finally managed to reduce it somewhat - not minimal, but the only dependency now is libcxx.

This is perhaps related to the known limitation of #include/import ordering with std, but it's a bit different; it requires both import std and #include <format> to repro, but it shows up even with the #include encapsulated into a module, and regardless of the import order in the consuming translation unit.

Compiler Explorer link.

Reproducing for me on both latest trunk and latest release.

// mod_a.cppm
export module mod_a;

import std;

auto something() -> void
{
    auto const buf = "a";
    auto x = std::format("{}", buf[0]);
}

// mod_b.cppm
module;

#include <format>

export module mod_b;

// source.cpp
import std;

// note: import order not relevant
import mod_a;
import mod_b;

auto func() -> void
{
    auto const buf = "a";
    auto x = std::format("{}", buf[0]);
}

auto dies() -> void
{
    std::string_view weird;
    auto x = std::format("{}", weird);
}

Output:

In module 'std' imported from /app/source.cpp:2:
/opt/compiler-explorer/clang-trunk-20250717/bin/../include/c++/v1/__format/format_functions.h:99:30: error: call to implicitly-deleted default constructor of 'formatter<std::__1::basic_string_view<char, std::__1::char_traits<char>>, wchar_t>'
   99 |       formatter<_Tp, _CharT> __f;
      |                              ^
/opt/compiler-explorer/clang-trunk-20250717/bin/../include/c++/v1/__format/format_functions.h:98:62: note: while substituting into a lambda expression here
   98 |     __parse_ = [](basic_format_parse_context<_CharT>& __ctx) {
      |                                                              ^
/opt/compiler-explorer/clang-trunk-20250717/bin/../include/c++/v1/__format/format_functions.h:393:25: note: in instantiation of function template specialization 'std::__format::__compile_time_handle<wchar_t>::__enable<std::__1::basic_string_view<char>>' requested here
  393 |       __handle.template __enable<_Tp>();
      |                         ^
/opt/compiler-explorer/clang-trunk-20250717/bin/../include/c++/v1/__format/format_functions.h:389:99: note: while substituting into a lambda expression here
  389 |   static constexpr array<__format::__compile_time_handle<_CharT>, sizeof...(_Args)> __handles_{[] {
      |                                                                                                   ^
source.cpp:16:26: note: in instantiation of template class 'std::__1::basic_format_string<wchar_t, std::__1::basic_string_view<char> &>' requested here
   16 |     auto x = std::format("{}", weird);
      |                          ^
/opt/compiler-explorer/clang-trunk-20250717/bin/../include/c++/v1/__format/formatter_string.h:141:63: note: default constructor of 'formatter<std::__1::basic_string_view<char>, wchar_t>' is implicitly deleted because base class '__disabled_formatter' has a deleted default constructor
  141 | struct formatter<basic_string_view<char, _Traits>, wchar_t> : __disabled_formatter {};
      |                                                               ^
/opt/compiler-explorer/clang-trunk-20250717/bin/../include/c++/v1/__format/formatter.h:25:3: note: '__disabled_formatter' has been explicitly marked deleted here
   25 |   __disabled_formatter()                                       = delete;
      |   ^

Note the bizarre reference to wchar_t.

[shafik]

CC @ChuanqiXu9

[ChuanqiXu9]

It will be helpful if you can provide a reproducer without any std headers.

[kamrann]

It will be helpful if you can provide a reproducer without any std headers.

I understand, and I want to help, but it's just infeasible. I spent a couple of hours reducing my code to the above. I just tried going further and after 45 minutes got it down only as far as this. It's already difficult to go further and would likely take me days to cut through all the format machinery. And presumably you meant the std module side as well, not just the included header.

If you have any suggestions I'm happy to look into it (I vaguely recall you mentioning some reduction tool in the past but don't remember if it works for all modules cases and can't find the reference), but trying to manually reduce std library code each time I hit a modules bug isn't practical. Which is a problem, as the majority of modules bugs I hit (and not only with Clang) point to somewhere in the std library code.

[ChuanqiXu9]

Thanks. I think it will be better to edit the std headers directly, especially not a lot code depend on . You may be able to achieve this by installing libc++'s headers (or libstdc++) to a specific path.

For the tool, here is an on going work at marxin/cvise#169 (comment), but I didn't try.

[kamrann]

For the tool, here is an on going work at marxin/cvise#169 (comment), but I didn't try.

Thanks, I'll take a look.

Thanks. I think it will be better to edit the std headers directly, especially not a lot code depend on . You may be able to achieve this by installing libc++'s headers (or libstdc++) to a specific path.

Presumably I'd need my build tool to also rebuild the std library on these modified headers, otherwise it would likely be UB, or anyway no longer the same test? Not sure if this is configurable. Alternatively I could dump the std module and just recreate a module from the format headers, but then is this even valid? As I recall, there is a special requirement by the standard that the std library can be both imported and included, which doesn't apply to normal code. Does Clang actually distinguish in practice?

[ChuanqiXu9]

Yes, after you change the std headers, you need to rebuild the std modules. You can edit the std module too. e.g., remove other components in the std module.

Now, in clang, the std module is no difference than other normal modules.

[kamrann]

I'm making a bit more progress, but I'm hacking out so much of the format implementation it's quite difficult to be sure that the error I'm seeing remains wrong (rather than just becoming an expected error because I've removed some code). I know the behaviour is wrong with the initial repro, but it's less obvious once all the meaning of the formatting code is taken away. So I have a question. Given a header something.h with some declarations, and:

// wrap.cppm
module;
#include <something.h>
export module wrap;

export namespace x {
	using x::something;
}

// m1.cppm
export module m1;
import wrap;

// use x::something in some way here

// m2.cppm
module;
#include <something.h>
export module m2;

// empty

// source.cpp
import wrap;

import m1;
import m2;

// use x::something in some way here

Is it safe to say that if the compiler errors on source.cpp, but doesn't error if #include <something.h> is commented out in m2.cppm, then there's a bug in the compiler?

[Bigcheese]

Yes, this should work assuming something.h doesn't have any code that causes ODR violations here (which is unlikely).

This looks like a bug in entity merging, which is a very bug prone part of Clang. This specific case would be "fixed" when Clang implements GMF pruning, but the underlying issue would still be present and could still be trigged in cases where the problematic decls aren't pruned.