summaryrefslogtreecommitdiffstats
path: root/src/corelib/text/qstringview.h
Commit message (Collapse)AuthorAgeFilesLines
* Revert "QStringView: simplify the constructor from QString"Marc Mutz2024-03-061-1/+10
| | | | | | | | | | | | | | | This reverts commit 7d18ad49a37440835bb38bd77bc4e0991387ada0. Reason for revert: This changes the constructor from being a template to being a normal function, so changes overload resolution. The commit message gave no indication on why this is safe. Since it's just a nice to have, revert instead of running the risk of breaking code. Pick-to: 6.7 Change-Id: Icd506e7221bb50c99f276f6a43c15403ec0be7a9 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Rename qIsConstantEvaluated() to q20::is_constant_evaluated()Marc Mutz2024-03-021-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | We should really try to avoid another almost-std-compatible-but-not-quite idiom. When qIsConstantEvaluated() was added, the rationale was given that this cannot be q20, because we can't implement it in all compilers. But we can: returning false is a perfectly legal implementation, and makes most users actually simpler because the #ifdef'ery can be dropped. There are only two users that still require the macro, because either they do different fallbacks depending on whether the implementation is trivial, or because they direct expected test outcomes. The INTEGRITY compiler complains "calling __has_builtin() in a constant expression", which we currently don't understand. To unblock this patch, and therefore the 6.7 release, hard-code INTEGRITY to return false. Amends 95e6fac0a5a1eee3aa23e4da0a93c6c25e32fb98. Pick-to: 6.7 Change-Id: If6cae902ff434f2ccceb6057cb053b7f304a604c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Ahmad Samir <a.samirh78@gmail.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* QStringView: use new comparison helper macrosIvan Solovev2024-02-201-19/+14
| | | | | | | | | | Replace the friend relational operators for QSV vs QSV and QSV vs QChar comparison. Task-number: QTBUG-117661 Change-Id: I547f69dac67c27b04864e56b383e75e213a17bfe Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Add QStringView vs byte array relational operatorsIvan Solovev2024-02-201-0/+18
| | | | | | | | | | | | | | | | | | | | ... by using the new comparison helper macors. Note that by providing helper functions for QByteArrayView, we can support all three types: QByteArray, QByteArrayView, and const char *. Use the regular QT_NO_CAST_FROM_ASCII and QT_RESTRICTED_CAST_FROM_ASCII guards to disable the operators if the cast from ASCII is forbidden. Also use QT_ASCII_CAST_WARN on each operator. This allows to enable related tests in tst_qstringapisymmetry. Task-number: QTBUG-117661 Task-number: QTBUG-108805 Change-Id: I0d77c30245d8b5ac4b8cfd98d650c1885aca2005 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* qTo*ViewIgnoringNull: further ignore nullsThiago Macieira2023-12-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | Commit ba5db13c8d197706ac3dec5d351b6684f809f2e4 ("QStringView: add internal qToStringViewIgnoringNull()") said: As long as a null QString still returns non-null data(), QStringView's QString constructor needs to call isNull(). That's a branch we often can do without, so add an internal function that bypasses this correctness check. It's internal, since we might have a Q6String that returns nullptr data() when null, which will remove the need for this function. For Qt 6, we made QString and QByteArray be able to return nullptr from data() when null... but that's not enabled by default yet. However, the begin() functions do return nullptr, so we can avoid the extra branch the commit was talking about. Task-number: QTBUG-119750 Change-Id: Ica7a43f6147b49c187ccfffd179e4cf032bc8565 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QString/QByteArray: further inline the most common indexOf operationsThiago Macieira2023-12-211-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the case of QString, the vast majority of searches are case- sensitive, so by inlining we make the user code call qustrchr() directly instead of QtPrivate::findString(). In the case of QByteArray, the call is to memchr(), which being a compiler intrinsic, may itself be inlined or even just resolved at compile time. In both cases, a great deal of searches use from=0. Benchmark for QByteArray; before: 8.83207052 nsecs per iteration 22.01568546 CPU cycles per iteration, 2.49 GHz 60.00000331 instructions per iteration, 2.725 instr/cycle 21.00000281 branch instructions per iteration, 2.38 G/sec After: 6.42561493 nsecs per iteration 16.01623130 CPU cycles per iteration, 2.49 GHz 49.00000261 instructions per iteration, 3.059 instr/cycle 18.00000211 branch instructions per iteration, 2.8 G/sec This shaves 6 cycles in the execution and 11 instructions (3 of which were branches), slightly improving the IPC raito, for the QByteArray case. For QByteArrayView, there are 2 fewer instructions (1 a branch), but the number of cycles is the same at 16. Task-number: QTBUG-119750 Change-Id: Ica7a43f6147b49c187ccfffd179e2204ebb6a348 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QString: inline indexOf() and use a QChar overloadThiago Macieira2023-12-211-2/+2
| | | | | | | | | | This is a repeat of the last commit, which did the same for QByteArray. No benchmarks in this commit, assuming the results are similar (at least for cs = Qt::CaseSensitive). Task-number: QTBUG-119750 Change-Id: Ica7a43f6147b49c187ccfffd179e1f852272af8b Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* String-ish: Add missing <string_view> #includesMarc Mutz2023-11-241-0/+1
| | | | | | | | | | Don't depend on transitive includes. Amends 96d67da420697cee10bdc537a1a592f6f22e2b8f. Change-Id: I3ec93e4d786af0babd36bb71a15222ffc3538e38 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QStringView: add isLower and isUpperAnton Kudryavtsev2023-11-021-0/+5
| | | | | | | | [ChangeLog][QtCore][QStringView] Added isLower() and isUpper() Change-Id: Ie6cd20bd375d42cbdfb17953b2307d025c31ec77 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QStringView: simplify the constructor from QStringGiuseppe D'Angelo2023-10-051-10/+1
| | | | | | | | | | We have to single QString out because of the isNull/isEmpty distinction. Still, we can avoid having a constructor template on it constrained on the argument being precisely QString. This is a historic remnant; in Qt 5 the constructor also worked with QStringRef. Change-Id: I5457a83d5b77887f57ea9910a826f729ec276d28 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* String classes: make first/last/chopped() delegate to sliced()Ahmad Samir2023-09-301-3/+3
| | | | | | | De-duplicates code. Change-Id: Id29511e7e571ed14f9e3cfd4355b901d81ea2562 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add a verify() method to all sequential containersAhmad Samir2023-09-281-8/+17
| | | | | | | | | | | | | | | | | | | A helper method encasuplating the asserts related to index into the container and length, modelled after the QVLA::verify(). `pos <= size` is OK because if pos == size, the e.g. sliced()'ed container is just going to be empty. Normalize how verify() is used, the first arg is an index and the second a length. This method is constexpr even in QString/QByteArray merely for consistency with similar methods in other string classes (this necessitates using `d.size` in verify() in QString/QBA because size() isn't constexpr). Change-Id: I90e3c56d76c802259297a06d11d46ee342a1daf2 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* String-like containers: add implicit conversions towards std:: string viewsGiuseppe D'Angelo2023-07-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Q{Any,}StringView: optimize lengthHelperContainer for the runtimeThiago Macieira2023-06-111-16/+2
| | | | | | | | | | | | | | | | | | | | Deduplicate it in the process by moving to qstringalgorithms.h. In non-constexpr contexts, both GCC and Clang were giving up in pre-calculating the length if the UTF-16 string literal was too big. For the old code, that was 14 and 16 characters respectively. That number can be raised by adding some Q_ALWAYS_INLINE and (for GCC's case), replacing std::char_traits::find() with std::find(). If that limit is exceeded, we call the newly introduced qustrnlen() function. qustrnlen() is just qustrchr(), like qstrnlen() is just memchr(). But it is introduced as a separate function so we could change implementation if we ever wished to, plus QStringView is only forward-declared at this point. Change-Id: Ieab617d69f3b4b54ab30fffd175c560d926db1c3 Reviewed-by: Ahmad Samir <a.samirh78@gmail.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Short-live qIsConstantEvaluated()Thiago Macieira2023-06-111-2/+2
| | | | | | | | | | | | | | This is not q20::is_constant_evaluated() because it does not replace that for all compilers. Instead, it's our own version of it that may return false even in constant contexts. However, for the majority of our users, it will work even in C++17 mode. Updated QStringView and QAnyStringView to use it, which are the only two places in all of Qt that used std::is_constant_evaluated(). Change-Id: Ieab617d69f3b4b54ab30fffd175c50c517589226 Reviewed-by: Ahmad Samir <a.samirh78@gmail.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Q{Any,}StringView: remove the GCC-specific compile-time contentThiago Macieira2023-06-111-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Because GCC isn't really working them out at compile time. First, for both lengthHelperPointer(), they don't get called on string literals such as return QStringView(u"Hello"); because the type hasn't decayed to a pointer, but is instead a char16_t[6]. No one writes constexpr auto str = u"Hello"; return QStringView(str); Second, even when you do write that, GCC is emitting the code to search for the null or non-ASCII byte at runtime, instead of pre-calculating it. That's not worth it because the code is not vectorized, even at -O3 and with a long string. Instead, let it get the length at runtime with QtPrivate::qustrlen(), which has vector code. Drive-by fix the QAnyStringView::lengthPointerHelper() to be constexpr, avoiding the same GCC warning that was fixed for QStringView in commit 4fd4082c3ab682f14911e6308ec5ccb400de34f9. Change-Id: Ieab617d69f3b4b54ab30fffd175c505cb66eac02 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
* Make compare(QU8SV) a non-template, document itMarc Mutz2023-03-091-16/+4
| | | | | | | | | | | | | | | | | Templates have different overload characteristics from normal functions, and treating q_no_char8_t and q_has_char8_t::QUtf8StingView separately is never necessary, as one implicitly converts into the other. Add docs for the new UTF-8 compare() functions. Amends b977ae371a753a82e1d0bb32c5b62099da663721. Found in API review. Pick-to: 6.5 6.5.0 Change-Id: I58b4b28a3eccde1976d71cfa3412b734d46f314d Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Apply q20::remove_cvref_t around the codeMarc Mutz2023-03-011-2/+3
| | | | | | | | | Found in API review. It's not BC-critical, but let's get this into 6.5 to minimize the diff to our future LTS. Pick-to: 6.5 Change-Id: Iaa63afad1d31f6edef29e1185897d925f47a094d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Q{Latin1,}StringView: invert members so the order is (data,size) in Qt7Thiago Macieira2022-12-061-5/+15
| | | | | | | | | | | Matches Q{Any,Utf8}StringView as well as std::basic_string_view in Microsoft's STL and LLVM libc++, but not GCC's libstdc++. Interestingly, it does match the order in libstdc++'s non-small std::basic_string. Applied for bootstrapped use, so we ensure this works and keeps working. Change-Id: I51d12ccdc56c4ad2af07fffd172db18254fff083 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Add In-place utf-8 case-insensitive comparisonsØystein Heskestad2022-12-021-0/+16
| | | | | | | | | | | Also add optimizations for more string comparisons and add tests and benchmarks. [ChangeLog][QtCore][QString] Added utf-8 case-insensitive comparisons Fixes: QTBUG-100235 Change-Id: I7c0809c6d80c00e9a5d0e8ac3ebb045cf7004a30 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Replace usages of Q_CLANG_QDOC with Q_QDOCLuca Di Sera2022-10-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | To allow the user to customize the C++ code that QDoc sees, so as to be able to work-around some limitations on QDoc itself, QDoc defines two symbols: Q_QDOC and Q_CLANG_QDOC, both of which are "true" during an entire execution of QDoc. At a certain point in time, QDoc allowed the user the choice between a custom C++ parser and a Clang based one. The Q_QDOC symbol would always be defined while the Q_CLANG_QDOC symbol would be defined only when the Clang based parser was chosen. In more recent times, QDoc always uses a Clang based parser, such that both Q_CLANG_QDOC and Q_QDOC are always defined, making them equivalent. To avoid using different symbols, and the possible confusion and fragmentation that derives from it, all usages of Q_CLANG_QDOC are now replaced by the equivalent usages of Q_QDOC. Change-Id: I5810abb9ad1016a4c5bbea99acd03381b8514b3f Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Eradicate QT_STRINGVIEW_LEVELMarc Mutz2022-08-041-7/+0
| | | | | | | | | | | | | | | | | | | | | | It was designed to gauge the impact of replacing QString functions with QStringView ones, as opposed to just overloading, but that never came to pass, for two reasons: 1. We never got to implement a full set of overloads with the pattern in a large enough library (QtCore) for results to matter. 2. QStringView doesn't accept everything that QString accepts, making it unsuitable as a drop-in replacement (QAnyStringView has that property, though, but we never added a QT_ANYSTRINGVIEW_LEVEL macro). So, R.I.P. QT_STRINGVIEW_LEVEL. Fixes: QTBUG-100861 Pick-to: 6.4 Change-Id: I0a9318177acb295e8eeeddfb345449112070c597 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QtBase: eradicate QT_STRINGVIEW_LEVEL usesMarc Mutz2022-07-201-8/+1
| | | | | | | | | | | | It's not used and not useful. The macro itself has to stay, for now, because Qt5Compat uses it, too. Task-number: QTBUG-100861 Pick-to: 6.4 6.3 6.2 Change-Id: I5d0557a6c959d6facf6e47f26786a9d365339e95 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Use SPDX license identifiersLucie Gérard2022-05-161-39/+3
| | | | | | | | | | | | | 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 remnants of the old Intel C++ compilerThiago Macieira2022-05-111-1/+1
| | | | | | | | | | | | | We don't support it any more. I don't think it has ever properly compiled Qt 6 (and it's no longer working for me against GCC 12's libstdc++ headers). If you report a bug against it, Intel support's first question is if you can try instead the new Clang/LLVM-based oneAPI C++ compiler. So we support only that one, which identifies itself as Q_CC_CLANG. Change-Id: I5ff8e16fcdcb4ffd9ab6fffd16eb57a092c8439e Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QtCore: Replace remaining uses of QLatin1String with QLatin1StringViewSona Kurazyan2022-03-261-8/+8
| | | | | | | Task-number: QTBUG-98434 Change-Id: Ib7c5fc0aaca6ef33b93c7486e99502c555bf20bc Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Add QStringView::localeAwareCompare()Sona Kurazyan2022-03-171-0/+2
| | | | | | | | | | | | | | QString already has a localeAwareCompare(QStringView, QStringView) static method. Use it in QStringView::localeAwareCompare(QStringView). [ChangeLog][QtCore][QStringView] Added QStringView::localeAwareCompare(). Task-number: QTBUG-98431 Change-Id: Iec3865a5439d9fb653cc1150da21042186bdee98 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Add an overload of QStringView::count() for QLatin1StringSona Kurazyan2022-03-091-0/+1
| | | | | | | | | | | | Required for the API symmetry between QStringView and QLatin1String. [ChangeLog][QtCore][QStringView] Added an overload of QStringView::count() for QLatin1String. Change-Id: Ic49a4b31e8f6f0969eff0f792654d23a60e06c49 Task-numer: QTBUG-98431 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QStringView: add missing constexpr so we can use is_constant_evaluatedThiago Macieira2022-02-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC 12 -std=c++20 says: qstringview.h:155:39: error: ‘std::is_constant_evaluated’ always evaluates to false in a non-‘constexpr’ function [-Werror=tautological-compare] With this, it's possible to declare: constexpr QStringView sv = u"Hello, World!"; QStringView f() { return sv; } And GCC will generate: movl $13, %eax leaq .LC0(%rip), %rdx ret Writing simply QStringView f() { return u"Hello, World!"; } Causes GCC to emit a comparison loop (the std::char_traits::length function), but at least there's no function call in either C++17 or 20. Clang 13 is able to reduce the loop to a constant and produces the same code as the constexpr variable in either mode. Pick-to: 5.15 6.2 6.3 Change-Id: I74249c52dc02478ba93cfffd16d282fa35a5b883 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QString et al: fix lastIndexOf() API asymmetryMarc Mutz2021-12-021-1/+3
| | | | | | | | | | | | | | | | | Commit 6cee204d56205e250b0675c9c6d4dd8a2367f3c4 introduced overloads of lastIndexOf() which drop the 'from' argument, inadvertently fixing QTBUG-80694, but failed to provide the new overloads for all existing lastIndexOf() overloads, making the fix for QTBUG-80694 incomplete. This patch completes the fix, by adding the missing overloads (for char-likes) and also adds the missing (non-regex) tests to tst_qstringapisymmetry. Also amends 1c164ec7f21a78025475c561a70b94d1e3dd6bb6. Fixes: QTBUG-80694 Change-Id: Ib4b3d597d658ce2edf01a2bce0d711ecea593d6e Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QS(V)/QBA(V)/QL1S::lastIndexOf: fix the offset calculationsGiuseppe D'Angelo2021-08-191-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When trying to fix 0-length matches at the end of a QString, be83ff65c424cff1036e7da19d6175826d9f7ed9 actually introduced a regression due to how lastIndexOf interprets its `from` parameter. The "established" (=legacy) interpretation of a negative `from` is that it is supposed to indicate that we want the last match at offset `from + size()`. With the default from of -1, that means we want a match starting at most at position `size() - 1` inclusive, i.e. *at* the last position in the string. The aforementioned commit changed that, by allowing a match at position `size()` instead, and this behavioral change broke code. The problem the commit tried to fix was that empty matches *are* allowed to happen at position size(): the last match of regexp // inside the string "test" is indeed at position 4 (the regexp matches 5 times). Changing the meaning of negative from to include that last position (in general: to include position `from+size()+1` as the last valid matching position, in case of a negative `from`) has unfortunately broken client code. Therefore, we need to revert it. This patch does that, adapting the tests as necessary (drive-by: a broken #undef is removed). Reverting the patch however is not sufficient. What we are facing here is an historical API mistake that forces the default `from` (-1) to *skip* the truly last possible match; the mistake is that thre is simply no way to pass a negative `from` and obtain that match. This means that the revert will now cause code like this: str.lastIndexOf(QRE("")); // `from` defaulted to -1 NOT to return str.size(), which is counter-intuitive and wrong. Other APIs expose this inconsistency: for instance, using QRegularExpressionIterator would actually yield a last match at position str.size(). Similarly, using QString::count would return `str.size()+1`. Note that, in general, it's still possible for clients to call str.lastIndexOf(~~~, str.size()) to get the "truly last" match. This patch also tries to fix this case ("have our cake and eat it"). First and foremost, a couple of bugs in QByteArray and QString code are fixed (when dealing with 0-length needles). Second, a lastIndexOf overload is added. One overload is the "legacy" one, that will honor the pre-existing semantics of negative `from`. The new overload does NOT take a `from` parameter at all, and will actually match from the truly end (by simply calling `lastIndexOf(~~~, size())` internally). These overloads are offered for all the existing lastIndexOf() overloads, not only the ones taking QRE. This means that code simply using `lastIndexOf` without any `from` parameter get the "correct" behavior for 0-length matches, and code that specifies one gets the legacy behavior. Matches of length > 0 are not affected anyways, as they can't match at position size(). [ChangeLog][Important Behavior Changes] A regression in the behavior of the lastIndexOf() function on text-related containers and views (QString, QStringView, QByteArray, QByteArrayView, QLatin1String) has been fixed, and the behavior made consistent and more in line with user expectations. When lastIndexOf() is invoked with a negative `from` position, the last match has now to start at the last character in the container/view (before, it was at the position *past* the last character). This makes a difference when using lastIndexOf() with a needle that has 0 length (for instance an empty string, a regular expression that can match 0 characters, and so on); any other case is unaffected. To retrieve the "truly last" match, one can pass a positive `from` offset to lastIndexOf() (basically, pass `size()` as the `from` parameter). To make calls such as `text.lastIndexOf(~~~);`, that do not pass any `from` parameter, behave properly, a new lastIndexOf() overload has been added to all the text containers/views. This overload does not take a `from` parameter at all, and will search starting from one character past the end of the text, therefore returning a correct result when used with needles that may yield 0-length matches. Client code may need to be recompiled in order to use this new overload. Conversely, client code that needs to skip the "truly last" match now needs to pass -1 as the `from` parameter instead of relying on the default. Change-Id: I5e92bdcf1a57c2c3cca97b6adccf0883d00a92e5 Fixes: QTBUG-94215 Pick-to: 6.2 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Q{*String,ByteArray}View::length(): use qsizetype, not intGiuseppe D'Angelo2021-04-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Looks like these ones have been forgotten in the Qt 5 -> 6 upgrade to qsizetype. Change them to return qsizetype as well, and fix the docs. Being entirely inline, non-exported classes, we should be able to get away with it without affecting binary compatibility. Moreover, there's no reason for keeping them deprecated. Requires some minor adjustments, just like the ones done for size()'s changes. [ChangeLog][QtCore][QStringView] The length() function now returns `qsizetype`, not `int`, for consistency with the other string and container classes in Qt. Following this change, it has been un-deprecated. [ChangeLog][QtCore][QAnyStringView] The length() function now returns `qsizetype`, not `int`, for consistency with the other string and container classes in Qt. Following this change, it has been un-deprecated. [ChangeLog][QtCore][QUtf8StringView] The length() function now returns `qsizetype`, not `int`, for consistency with the other string and container classes in Qt. Following this change, it has been un-deprecated. [ChangeLog][QtCore][QByteArrayView] The length() function now returns `qsizetype`, not `int`, for consistency with the other string and container classes in Qt. Following this change, it has been un-deprecated. Fixes: QTBUG-92496 Change-Id: Ie0f4939d1083884e95d4725f891b6c6764532cb8 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Mark places where we missed conversion to unicode character typesEdward Welbourne2021-01-081-1/+1
| | | | | | | | | | | We should use char32_t for the toUcs4() methods of QString and QStringView and use char16_t for QString::utf16(), thereby matching QStringView. These naturally imply knock-on changes in various places. Unfortunately, we didn't make those changes in Qt 6, so they'll have to wait for Qt 7. Change-Id: I18451d4b31b76658092e19d3fcbc8bc0fe5ce307 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QStringView: add constBegin and constEndThiago Macieira2020-12-121-0/+2
| | | | | | Change-Id: I55083c2909f64a1f8868fffd164f21118a9d3ec5 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QStringView: add some QRegularExpression-related overloadsGiuseppe D'Angelo2020-12-101-0/+20
| | | | | | | | | [ChangeLog][QtCore][QStringView] Added the indexOf(), contains(), lastIndexOf() and count() methods taking a QRegularExpression. Fixes: QTBUG-89050 Change-Id: Ic726754f67e06b3764302d2fad252e0378a77afc Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add noexcept to slicing and indexing of QStringViewAllan Sandfeld Jensen2020-11-041-11/+11
| | | | | | | | None of those paths should be able to cast. Change-Id: I947f26c0aae134076499c9f80e910b0257d2bc62 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Make remaining String binary comparisons hidden friendsAllan Sandfeld Jensen2020-10-261-0/+23
| | | | | | | | | Also forced the introduction of explicit comparisons with char16_t* and std::nullptr_t. Change-Id: I8e32c14a1d3aeec234ee070b9fefc6af06db0fda Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Use c++20 when available at compile timeAllan Sandfeld Jensen2020-09-251-8/+7
| | | | | | | | Also std::end is constexpr where std::next sometimes isn't always with sanitizers active. Change-Id: Ibe4c11eb4945fb286247e841b6a7f6cc3ff1eaa6 Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
* Replace Q_REQUIRED_RESULT with [[nodiscard]]Allan Sandfeld Jensen2020-09-251-85/+85
| | | | | | | It was already used many places directly making the code inconsistent. Change-Id: I3b14bc6c333640fb3ba33c71eba97e78c973e44b Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Q(Any|Utf8)StringView: move array size deduction feature to fromArrayMårten Nordheim2020-09-181-2/+8
| | | | | | | | | | | | | 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>
* Convert QStringView::toWCharArray() to return qsizetypeEdward Welbourne2020-08-281-1/+1
| | | | | | | | As requested in a ### Qt6 comment. Task-number: QTBUG-85700 Change-Id: I28a02bf49f4a6455a21a6032179318ce2915b8ca Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Move QStringRef and remains to Qt5CompatKarsten Heimrich2020-08-201-8/+3
| | | | | | | | | 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-28/+28
| | | | | | | | 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>
* Fix warning in QStringView::compare(QChar) on qsizetype->intThiago Macieira2020-07-301-1/+4
| | | | | | | | | | | | | | | | | | size() - 1 is converted to int as the result, but size() is a qsizetype and could be bigger than INT_MAX. So rewrite to not depend on the cast. This was introduced on b2f79cceb11dfd15ac9eea631bc18ad6b036eb91. I could have replaced size() - 1 with int(size() > 1) - 1, but that's even more complex. To simplify, I split the function in two while retaining the C++11 constexpr requirements. Bonus: removes the use of the ambiguously-named "empty()" function that looks like a verb. Fixes: QTBUG-85665 Pick-to: 5.15 Change-Id: Ieffc3453b88c4517a1dbfffd162338fdb084a376 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Rename from() to sliced()Lars Knoll2020-07-061-1/+1
| | | | | | | | After API discussions, agreement was that from(n) is a bad name for the method. Let's go with sliced(n) instead. Change-Id: I0338cc150148a5008c3ee72bd8fda96fb93e9c35 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use QList instead of QVector in corelibJarek Kobus2020-06-251-1/+1
| | | | | | | | | | Applied to headers only. Source file to be changed separately. Omitted statemachine for now to avoid conflicts. Omitted qmetatype.h for now - to be handled later. Task-number: QTBUG-84469 Change-Id: I317376037a62467c313467d92955ad0b7473aa97 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Don't truncate parameters passed to QStringView::{first/last/from/slice}Sona Kurazyan2020-06-191-4/+4
| | | | | | | | QStringView doesn't need to convert qsizetype parameters to int. Change-Id: Iba8b5259ab3ed7a24a57bb6748446fd3e45bb182 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Rename new slice() method sliced()Marc Mutz2020-06-111-1/+1
| | | | | | | | | | | | | | The recently-added slice() method has the problem that it's a noun as well as a verb in the imperative. Like std::vector::empty, which is both an adjective and a verb in the imperative, this may cause confusion as to what the function does. Using the passive voice form of slice(), sliced(), removes the confusion. While it can be read as an adjective, too, that doesn't change the meaning compared to the verb form. Change-Id: If0aa01acb6cf5dd5eafa8226e3ea7f7a0c9da4f1 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Ensure left/right/mid behave in a compatible wayLars Knoll2020-06-091-8/+18
| | | | | | | | | | | | | | | | | | | | QString and QStringRef did bounds checking for left/right/mid, whereas QStringView was asserting on out of bounds. Relax the behavior for QStringView and do bounds checking on pos/n as well. This removes a source of potentially hidden errors when porting from QStringRef (or QString) to QStringView. Unfortunately, one difference remains, where QByteArray::left/right() behaves differently (and somewhat more sane) than QString and QStringRef. We're keeping the difference here, as it has been around for many years. Mark left/right/mid as obsolete and to be replaced with the new first/last/slice methods. Change-Id: I18c203799ba78c928a4610a6038089f27696c22e Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Implement first/last/from and slice() for string-like classesLars Knoll2020-06-081-0/+9
| | | | | | | | | | | | These methods are scheduled as a replacement for left/right/mid() in Qt 6 with a consistent, narrow contract that does not allow out of bounds indices, and therefore does permit faster implementations. Change-Id: Iabf22e8d4f3fef3c5e69a17f103e6cddebe420b1 Reviewed-by: Alex Blasche <alexander.blasche@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-13 10:10:11 +0000