summaryrefslogtreecommitdiffstats
path: root/tests/auto/corelib/text/qstringview/tst_qstringview.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Change license for tests filesLucie Gérard2024-02-041-1/+1
| | | | | | | | | | | | According to QUIP-18 [1], all tests file should be LicenseRef-Qt-Commercial OR GPL-3.0-only [1]: https://contribute.qt-project.org/quips/18 Pick-to: 6.7 Task-number: QTBUG-121787 Change-Id: I9657df5d660820e56c96d511ea49d321c54682e8 Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
* tst_QStringView: don't go through the QString constructorThiago Macieira2024-01-141-1/+1
| | | | | | | | Amends d351a97e85e5ed8acd7ad1357ef76dc2e0ad639f. Pick-to: 6.2 6.5 6.6 6.7 Change-Id: I5201966b308e48989c06fffd17a9aa4d086e6039 Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
* QString::arg: don't pass nullptr to memcpy()Thiago Macieira2024-01-111-0/+4
| | | | | | | | | | | | | | | | | | A null QString / QStringView has a null begin pointer stored as its array beginning (something we hide a little in the QString::data() function, but not in QStringView::data()). We've been passing a null pointer to memcpy() every time someone passed a null QStringView for QString's single-argument arg() call, though not the multi-string arg() version (which is the only one QStringView offers). Commit f5021835dfb4b0bf974794b598cbdf9f0f95898d made this worse by making QStringViews created from null QStrings retain the nullness (as was intended). Fixes: QTBUG-120624 Pick-to: 6.2 6.5 6.6 6.7 Change-Id: I6e2677aad2ab45759db2fffd17a870639b19340b Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* String-like containers: add implicit conversions towards std:: string viewsGiuseppe D'Angelo2023-07-131-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In C++20 std::basic_string_view has gained a range constructor (like QStringView always had), but that range constructor has been made explicit. This means we can't just pass a QString(View) to a function taking a u16string_view. The consensus seems to be that that types that should implictly convert towards stdlib's string views should do that via implicit conversion operators. This patch adds them for * QByteArrayView => std::string_view * QString(View) => std::u16string_view * QUtf8StringView => std::string_view or std::u8string_view, depending on the storage_type QLatin1StringView doesn't have a matching std:: view so I'm not enabling its conversion. QByteArray poses a challenge, in that it already defines a conversion towards const char *. (One can disable that conversion with a macro.) That conversion makes it impossible to support: QByteArray ba; std::string_view sv1(ba); // 1 std::string_view sv2 = ba; // 2 because: * if only operator const char *() is defined, then (2) doesn't work (situation right now); * if both conversions to const char * and string_view are defined, then (1) is ambiguous on certain compilers (MSVC, QCC). Interestingly enough, not on GCC/Clang, but only in C++17 and later modes. I can't kill the conversion towards const char * (API break, and we use it *everywhere* in Qt), hence, QByteArray does not get the implicit conversion, at least not in this patch. [ChangeLog][QtCore][QByteArrayView] Added an implicit conversion operator towards std::string_view. [ChangeLog][QtCore][QString] Added an implicit conversion operator towards std::u16string_view. [ChangeLog][QtCore][QStringView] Added an implicit conversion operator towards std::u16string_view. [ChangeLog][QtCore][QUtf8StringView] Added an implicit conversion operator towards std::string_view (QUtf8StringView is using char as its storage type in Qt 6). Note that QUtf8StringView is planned to use char8_t in Qt 7, therefore it is expected that the conversion will change towards std::u8string_view in Qt 7. Change-Id: I6d3b64d211a386241ae157765cd1b03f531f909a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* tst_Q(Any)StringView: check conversion from winrt::hstringMarc Mutz2023-03-311-0/+17
| | | | | | | | | | | | | | | | Instead of adding more QString::fromMyFavoriteStringImpl(), just check that QStringView{myFavoriteStringImpl}.toString() works. It does. Pick-to: 6.5 Task-number: QTBUG-111886 Change-Id: I337282611360b4a56a10c8acfd2d7d53ea196d5b Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Make XmlStringRef convertible to QAnyStringView/QStringViewMarc Mutz2022-11-291-0/+3
| | | | | | | | | | | | | | | | | Both QStringView and QAnyStringView implicitly convert from any container with a fitting value_type, and working std::data, std::size, std::begin and std::end. Add these missing operations (and complementary ones) to XmlStringRef, so it implicitly converts to QStringView and QAnyStringView, too. Add a check to that effect and remove the now-superfluous operator QStringView(). Task-number: QTBUG-103302 Change-Id: I89d586cf64447a82022e06d546d7ee8339fc6dc7 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Port from qAsConst() to std::as_const()Marc Mutz2022-10-111-1/+1
| | | | | | | | | | | | | | | | We've been requiring C++17 since Qt 6.0, and our qAsConst use finally starts to bother us (QTBUG-99313), so time to port away from it now. Since qAsConst has exactly the same semantics as std::as_const (down to rvalue treatment, constexpr'ness and noexcept'ness), there's really nothing more to it than a global search-and-replace, with manual unstaging of the actual definition and documentation in dist/, src/corelib/doc/ and src/corelib/global/. Task-number: QTBUG-99313 Change-Id: I4c7114444a325ad4e62d0fcbfd347d2bbfb21541 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Use SPDX license identifiersLucie Gérard2022-05-161-27/+2
| | | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Remove checks for features available in C++17Ievgenii Meshcheriakov2021-10-021-12/+0
| | | | | | | | | | This patch removes most of the checks that are made using C++20 __cpp_* macros for features available in C++17 and earlier. Library feature check macros (__cpp_lib_*) are unaffected. Change-Id: I557b2bd0d4ff09b13837555e9880eb28e0355f64 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Get rid of Q_COMPILER_CONSTEXPR checksAllan Sandfeld Jensen2020-11-171-2/+0
| | | | | | | Is required now. Change-Id: I62e95929d1649ea1390392230b619bd56d2a0349 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QChar: make construction from integral explicitGiuseppe D'Angelo2020-11-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QChar should not be convertible from any integral type except from char16_t, short and possibly char (since it's a direct superset). David provided the perfect example: if (str == 123) { ~~~ } compiles, with 123 implicitly converted to QChar (str == "123" was meant instead). But similarly one can construct other scenarios where QString(123) gets accidentally used (instead of QString::number(123)), like QString s; s += 123;. Add a macro to revert to the implicit constructors, for backwards compatibility. The breaks are mostly in tests that "abuse" of integers (arithmetic, etc.). Maybe it's time for user-defined literals for QChar/QString, but that is left for another commit. [ChangeLog][Potentially Source-Incompatible Changes][QChar] QChar constructors from integral types are now by default explicit. It is recommended to use explicit conversions, QLatin1Char, QChar::fromUcs4 instead of implicit conversions. The old behavior can be restored by defining the QT_IMPLICIT_QCHAR_CONSTRUCTION macro. Change-Id: I6175f6ab9bcf1956f6f97ab0c9d9d5aaf777296d Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QStringView test: avoid narrowingGiuseppe D'Angelo2020-11-071-2/+2
| | | | | | | Use '\0' (char) instead of 0 (int). Change-Id: I866d08e7b07ae555fcf0244a8614e3e04a0bc567 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix some compiler warnings from testsVolker Hilsheimer2020-10-161-2/+2
| | | | | | | | For iterators that return a value, don't use reference in ranged for, and cast numeric literal to correct size type for QCOMPARE. Change-Id: Idfd09dbc2ef3ab1bf025c7859ea6e2e9572bc9a1 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Q(Any|Utf8)StringView: move array size deduction feature to fromArrayMårten Nordheim2020-09-181-1/+33
| | | | | | | | | | | | | The constructor taking an array literal will now stop at the first null-terminator encountered. And fromArray is introduced which only supports array literals. Constructs a view of the full size. Explicit so it shouldn't be surprising. Change-Id: I1497c33a5c12453a95e87c990abe6335b2817081 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Move QStringRef and remains to Qt5CompatKarsten Heimrich2020-08-201-52/+0
| | | | | | | | | Export some private functions from QUtf8 to resolve undefined symbols in Qt5Compat after moving QStringRef. Task-number: QTBUG-84437 Change-Id: I9046dcb14ed520d8868a511d79da6e721e26f72b Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Replace Qt CONSTEXPR defines with constexprAllan Sandfeld Jensen2020-08-141-1/+1
| | | | | | | | Both normal and relaxed constexpr are required by our new minimum of C++17. Change-Id: Ic028b88a2e7a6cb7d5925f3133b9d54859a81744 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Use QList instead of QVector in corelib testsJarek Kobus2020-07-071-5/+5
| | | | | | Task-number: QTBUG-84469 Change-Id: Ic80fde5517aed363f17d0da55cadcc958c3c8895 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Port Q_STATIC_ASSERT(_X) to static_assertGiuseppe D'Angelo2020-06-191-82/+82
| | | | | | | | | | | | | | | | | There is no reason for keep using our macro now that we have C++17. The macro itself is left in for the moment being, as well as its detection logic, because it's needed for C code (not everything supports C11 yet). A few more cleanups will arrive in the next few patches. Note that this is a mere search/replace; some places were using double braces to work around the presence of commas in a macro, no attempt has been done to fix those. tst_qglobal had just some minor changes to keep testing the macro. Change-Id: I1c1c397d9f3e63db3338842bf350c9069ea57639 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Also check QStringView(std::nullptr_t) for constexpr'nessMarc Mutz2020-06-111-0/+8
| | | | | | Pick-to: 5.15 Change-Id: I85967caa014fa93d2cd3f26b63e4a85414f6a803 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QString/View: add tokenize() member functionsMarc Mutz2020-06-061-1/+166
| | | | | | | | | [ChangeLog][QtCore][QString, QStringView, QLatin1String] Added tokenize(). Change-Id: I5fbeab0ac1809ff2974e565129b61a6bdfb398bc Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QStringView: add converting constructor from array-like containersGiuseppe D'Angelo2020-05-141-7/+70
| | | | | | | | | | | | | | | | | Centralize, rather than keeping adding constructors from any array-like container. A more robust implementation, likely following the converting constructor for std::span ([span.cons]), is out of scope for C++17 and will require C++20's ranges and concepts. [ChangeLog][QtCore][QStringView] QStringView can now be constructed from any contiguous container, as long as they hold string-like data. For instance, it's now possible to create a QStringView object from a std::vector<char16_t>, a QVarLengthArray<ushort> and so on. Change-Id: I7043eb194f617e98bd1f8af1237777a93a6c5e75 Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
* tst_stringview: remove dead codeMarc Mutz2020-05-081-54/+0
| | | | | | | | | | wchar_t hasn't been QStringView's storage_type for a very long time (at least since 5.10). And in Qt 6, we require char16_t support not only in the compiler, but also in the stdlib, so drop the guards and the alternative code paths. Change-Id: I99f28b575f61c16a2497840708beaa4b54a80f57 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* tst_qstringview: modernize functions in help namespaceMarc Mutz2020-05-081-4/+4
| | | | | | | | | | | | | They don't work with std::span, since std::span has neither const_iterator nor cbegin()/cend(). To fix, perfectly forward the return type with decltype(auto) instead of mentioning T::const_iterator, and rely on the const-qualfication of the help::c{r,}{begin,end}() functions' arguments to select the correct T::{r,}{begin,end}() overload. Change-Id: I4992d4bd521d2dc0f9ea51ae70cde8286ae543a5 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QStringView: add a test for overload resolution versus QStringGiuseppe D'Angelo2020-01-091-0/+58
| | | | | | | | | | | | | | | | | | | | In the presence of multiple overloads of a function taking either QString or QStringView, QStringView should always be preferred. The rationale is that the QStringView overload may have been added "later" (read: the function was written when QStringView was not available yet, so it took QString), and the fact that a function with the _same name_ offers a QStringView overload implies the function never needed to store/own the string in the first place. Add a (compile-time) test for this preference. This is in preparation for a future QString(char16_t*) constructor (in Qt 5.15 / Qt 6). Change-Id: I60a435e494b653548f8f8d52c5d7e7cac2cc875a Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Deprecate QStringViewLiteralMarc Mutz2019-08-101-6/+6
| | | | | | | | | | | | | | | | | As a macro, we can't directly deprecate it, but need to make it call something deprecated. That is a new ctor with a new enum type added. The type might be useful for other such ventures, so put it into qglobal.h Remove the QT_NO_UNICODE_LITERAL protection, as it's always false these days, and QT_UNICODE_LITERAL is unconditionally #defined a 20 lines above. [ChangeLog][QtCore][QStringView] Deprecated the (undocumented) QStringViewLiteral macro. Just use u"" or QStringView(u"") instead. Change-Id: I9141320225037e1bc6b7f920bf01a9d0144fdac2 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Port from QStringViewLiteral to u""Marc Mutz2019-07-291-6/+6
| | | | | | | | | Now that all our supported compilers know char16_t, we no longer need QStringViewLiteral, whose only purpose in life was to turn u"" into L"" for MSVC < 2015. Change-Id: I25a094fe7992d9d5dbeb4a524d9e99e043dcb8ce Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Move text-related code out of corelib/tools/ to corelib/text/Edward Welbourne2019-07-101-0/+682
This includes byte array, string, char, unicode, locale, collation and regular expressions. Change-Id: I8b125fa52c8c513eb57a0f1298b91910e5a0d786 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-02 00:54:57 +0000