QStringView: refuse construction from QStringRef

When QStringRef was moved out of QtCore, it was also incorrectly removed from the if_compatible_container constraint, causing QStringView{sr} to still match the general container QStringView ctor overload, which doesn't preserve null'ness if data() doesn't return null. By refusing to provide a constructor from QStringRef, we force the compiler to use QStringRef's implicit conversion operators instead. This transitively affects QAnyStringView in the same way. The tests can, naturally, only be in qt5compat, so define a macro to communicate to tst_QStringRef whether it compiles against a fixed QtCore or not. Fixes: QTBUG-122797 Fixes: QTBUG-122798 Pick-to: 6.5 Change-Id: I64b75a8e421d2b6185615e3288ce3ad7fd8f15f9 Reviewed-by: Ahmad Samir <[email protected]> (cherry picked from commit a0e6539) Reviewed-by: Qt Cherry-pick Bot <[email protected]> (cherry picked from commit 9e86f73)
qt · Dec 17, 2024 · 029af22 · 029af22
1 parent b313044
commit 029af22
Show file tree

Hide file tree

Showing 2 changed files with 3 additions and 0 deletions.
diff --git a/src/corelib/text/qstringfwd.h b/src/corelib/text/qstringfwd.h
@@ -36,6 +36,7 @@ class QLatin1String;
 using QLatin1StringView = QLatin1String;
 #endif
 class QString;
+class QStringRef; // defined in qt5compat
 class QStringView;
 template <bool> class QBasicUtf8StringView;
 class QAnyStringView;

diff --git a/src/corelib/text/qstringview.h b/src/corelib/text/qstringview.h
@@ -64,6 +64,8 @@ struct IsContainerCompatibleWithQStringView<T, std::enable_if_t<std::conjunction
 
             // These need to be treated specially due to the empty vs null distinction
             std::negation<std::is_same<std::decay_t<T>, QString>>,
+#define QSTRINGVIEW_REFUSES_QSTRINGREF 1
+            std::negation<std::is_same<q20::remove_cvref_t<T>, QStringRef>>, // QStringRef::op QStringView()
 
             // Don't make an accidental copy constructor
             std::negation<std::is_same<std::decay_t<T>, QStringView>>