Waybar fails to compile with clang/libcxx because of date/tz.h

[theoparis]

A error in the header seems to be causing waybar to fail to compile. dev-libs/date (this library) compiles fine though 🤔

/usr/include/date/tz.h:244:8: error: use of overloaded operator '<<' is ambiguous (with operand types 'basic_ostream<char, char_traits<char>>' and 'const sys_seconds' (aka 'const time_point<std::chrono::system_clock, std::chrono::duration<long long, std::ratio<1, 1>>>'))
  238 |     os << tp << " is in a gap between\n"
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  239 |        << local_seconds{i.first.end.time_since_epoch()} + i.first.offset << ' '

uname -a:
Linux gigatop 6.5.0-rc2-gentuwu-kernel-g84f54d4966f4 #4 SMP PREEMPT_DYNAMIC Sat Sep 9 20:57:48 PDT 2023 x86_64 Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz GenuineIntel GNU/Linux

[HowardHinnant]

I suspect that this is a conflict with C++20. This library isn't compatible with C++20 because it was adopted into C++20. The ambiguity is likely between the streaming operator for sys_time in date, and the same operator in std::chrono.

[marcovc]

I'm seeing this as well on mac os. It happens after I updated clang from 16 to 17. Interestingly, it does not seem to happen on linux using the same compiler version (17).

[marcovc]

Additionally, here including <chrono> does not seem to define "std::chrono::time_zone" so it seems clang 17 still does not support std timezone objects.

[HowardHinnant]

My latest info is that chrono C++20 is supported on MSVC, gcc-14 (which hasn't shipped yet), and not on llvm.

[marcovc]

Right. Do you have any advice on how to work around this issue on clang 17 then? I'd like to still use this header for time zone arithmetic on my project...

I guess I don't really understand what changed from clang 16 to 17 that causes this error.

[marv]

Right. Do you have any advice on how to work around this issue on clang 17 then? I'd like to still use this header for time zone arithmetic on my project...

I guess I don't really understand what changed from clang 16 to 17 that causes this error.

git diff llvmorg-16.0.0..llvmorg-17.0.0 -- libcxx/include/__chrono/ostream.h

@@ -33,10 +37,28 @@
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
-#if _LIBCPP_STD_VER > 17 && !defined(_LIBCPP_HAS_NO_INCOMPLETE_FORMAT)
+#if _LIBCPP_STD_VER >= 20
 
 namespace chrono {
 
+template <class _CharT, class _Traits, class _Duration>
+_LIBCPP_HIDE_FROM_ABI basic_ostream<_CharT, _Traits>&
+operator<<(basic_ostream<_CharT, _Traits>& __os, const sys_time<_Duration> __tp) {
+  return __os << std::format(__os.getloc(), _LIBCPP_STATICALLY_WIDEN(_CharT, "{:L%F %T}"), __tp);
+}
+
+template <class _CharT, class _Traits, class _Duration>
+_LIBCPP_HIDE_FROM_ABI basic_ostream<_CharT, _Traits>&
+operator<<(basic_ostream<_CharT, _Traits>& __os, const file_time<_Duration> __tp) {
+  return __os << std::format(__os.getloc(), _LIBCPP_STATICALLY_WIDEN(_CharT, "{:L%F %T}"), __tp);
+}
+
+template <class _CharT, class _Traits, class _Duration>
+_LIBCPP_HIDE_FROM_ABI basic_ostream<_CharT, _Traits>&
+operator<<(basic_ostream<_CharT, _Traits>& __os, const local_time<_Duration> __tp) {
+  return __os << sys_time<_Duration>{__tp.time_since_epoch()};
+}
+
 // Depending on the type the return is a const _CharT* or a basic_string<_CharT>
 template <class _CharT, class _Period>
 _LIBCPP_HIDE_FROM_ABI auto __units_suffix() {

libc++ 17.0.0 introduced an output operator for sys_time<_Duration>, now when date/tz.h and libc++'s <chrono> header are used in the same translation unit the compiler can't decide which version to use, the one from libc++ or date (https://github.com/HowardHinnant/date/blob/master/include/date/date.h#L4212)

Unfortunately I don't have a good idea how to work around it :-/

[marcovc]

Thanks.

I tried to specialize the template for that function for the concrete types it is complaining about, hoping that it would desambiguate, but with no luck.

I still don't understand how using proper namespaces cannot prevent this from happening.

How about introducing some macro that would disable these redundant definitions of operator<<? Could even be set as a function of being compiled with clang 17?

[thesamesam]

See llvm/llvm-project#67983.