Hello, I think I discovered a bug in the latest ROOT version under C++20.
Symptoms to reproduce are as follows:
- Create a C++20 project that depends on both ROOT and Qt.
- Include
TROOT.h
andQObject
in a header file. - Declare a
struct
in the same header and annotate it using theQT_DECLARE_METATYPE
macro.
Expected behavior: the project compiles.
Actual behavior: compiation fails with the following error message:
/tmp/foo.h:378:1: error: use of overloaded operator '==' is ambiguous (with operand types 'QByteArrayView' and 'const char[13]')
378 | Q_DECLARE_METATYPE(foo)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/qt6/QtCore/qmetatype.h:1504:34: note: expanded from macro 'Q_DECLARE_METATYPE'
1504 | #define Q_DECLARE_METATYPE(TYPE) Q_DECLARE_METATYPE_IMPL(TYPE)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/qt6/QtCore/qmetatype.h:1519:42: note: expanded from macro 'Q_DECLARE_METATYPE_IMPL'
1519 | if (QByteArrayView(name) == (#TYPE)) { \
| ~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~
/usr/include/qt6/QtCore/qbytearrayview.h:318:24: note: candidate function
318 | friend inline bool operator==(QByteArrayView lhs, QByteArrayView rhs) noexcept
| ^
/usr/include/TString.h:856:15: note: candidate function
856 | inline Bool_t operator==(const std::string_view &s1, const char *s2)
| ^
/usr/include/TString.h:851:15: note: candidate function (with reversed parameter order)
851 | inline Bool_t operator==(const char *s1, const std::string_view &s2)
It seems that when both Qt and ROOT are included in the same compilation unit, operator==(const char*, const std::string_view&)
competes with operator==(QByteArrayView, QByteArrayView)
. Unfortunately for me as a user, I cannot really modify ROOT’s or Qt’s header files. My only mitigation is that I have to be extraordinarily careful about what ROOT headers I include in my Qt app.
I intend to report this also to Qt folks as this is primarily their bug, but since they are not exactly known for expediency, it would be super cool if TString.h
could somehow detect and prevent ambiguity from occurring. Or perhaps respond to a pre-processor macro?
Any ideas/suggestions would be welcome.
ROOT Version: 6.30/06
Platform: Linux x86_64
Compiler: clang version 17.0.6, x86_64-pc-linux-gnu