path: root/src/3rdparty/libgq
diff options
authorMarc Mutz <>2021-07-22 19:13:27 +0200
committerMarc Mutz <>2021-07-24 00:33:09 +0200
commita7da8e0dab8f6290b2af9bc12c0cd391af30bfb7 (patch)
tree5cd7fd3100336da8c78c53a9dca688f592367c20 /src/3rdparty/libgq
parentbd594f945773f713ca493fd7b040fde8a12bdf87 (diff)
QWidget: cope with QObject::connect()'s incomplete SFINAE-friendliness
The plan for QObject::connect() (perfect) forwarders, such as QWidget::addAction(), was to just use a variant of the Detection Idiom to see whether QObject::connect() with the arguments as given would compile and SFINAE out the forwarder otherwise. It turns out that the "functor" overload of QObject::connect(), in particular, is severly underconstrained and accepts e.g. QKeySequence as a function object, only erroring out via a static_assert() in the body of the function, and thus at instantiation time and not, as needed, at overload resolution time. At the same time, we don't really want QObject::connect() to SFINAE out on argument mismatches between signal and slot, because the resulting error messages would be ... unkind to users of the API. We would like to keep the static_assert()s for easier error reporting. Reconciling these two contradicting requirements has so far eluded this author, so for now, to unblock progress, we explicitly black- and, in one case, white-list possible arguments. Because QKeySequence, in particular, is implicitly constructible from int(!), and therefore any enum type(!), incl. Qt::ConnectionType, we need to do way too much coding in the addAction() constraints. Hopefully, we'll be able to fix the issue at the root cause, in QObject, before Qt 6.3 is out, but until then, this is an ok-ish stop-gap measure. Add thorough overload set checks (positive ones only, for now) to tst_qwidget and tst_qmenu. Change-Id: Ia05233df818bc82ecc924fc44c1b349af41cbbf1 Reviewed-by: Volker Hilsheimer <>
Diffstat (limited to 'src/3rdparty/libgq')
0 files changed, 0 insertions, 0 deletions