boost::u32regex does not compile on latest libc++ (19.0) due to use of UChar32 / int32_t as charT

[JoachimSchurig]

This source

#include <boost/regex.hpp>
#include <boost/regex/icu.hpp>

int main()
{
	boost::u32regex re(boost::make_u32regex(R"(All.*)"));
	auto pattern = re.str(); // fails

	return 0;
}

when built with clang++ -I /opt/homebrew/include -I /opt/homebrew/opt/icu4c/include -std=c++17 test.cpp -o test
fails with

In file included from test.cpp:1:
In file included from /opt/homebrew/include/boost/regex.hpp:34:
In file included from /opt/homebrew/include/boost/regex/v5/regex.hpp:29:
In file included from /opt/homebrew/include/boost/regex/v5/regex_workaround.hpp:29:
In file included from /opt/homebrew/include/boost/throw_exception.hpp:21:
In file included from /opt/homebrew/include/boost/exception/exception.hpp:9:
In file included from /opt/homebrew/include/boost/assert/source_location.hpp:13:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/string:821:42: error: implicit instantiation of undefined template 'std::char_traits<int>'
  821 |   static_assert(is_same<_CharT, typename traits_type::char_type>::value,
      |                                          ^
test.cpp:7:20: note: in instantiation of template class 'std::basic_string<int>' requested here
    7 |         auto pattern = re.str(); // may fail
      |                           ^

on latest AppleClang 17.0.0.17000013.

According to MS STL issue #4935, libc++ 19.0 has restricted instantiations for std::char_traits<charT> to the standard character types char, wchar_t, char8_t, char16_t, char32_t, which lets boost::u32regex::str() fail here:

std::basic_string<charT>  str()const
{
    return m_pimpl.get() ? m_pimpl->str() : std::basic_string<charT>();
}

Tested with boost v1.87 and ICU 77 in Xcode 16.3 / AppleClang 17.0.0

[JoachimSchurig]

This is the commit to libc++ that introduced the breaking change: llvm PR #72694

[JoachimSchurig]

and this is the followup (probably on this report) in the llvm issue tracker: llvm #134425