Strictly speaking, we did want to compare pointers, but char* are
special with QCOMPARE in that the pointed-to strings are compared, not
the pointers. So this wasn't doing what we wanted it to do.
We could static_cast to void* to do it, but subtracting one from the
other also gets us what we want, with simpler code. The drawback is that
if appendToBuffer() ever returns nullptr, we'll print a huge number as
the offset.
Found by Valgrind:
==3769588== Conditional jump or move depends on uninitialised value(s)
==3769588== at 0x483FEDC: strcmp (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==3769588== by 0x4C41EB6: qstrcmp(char const*, char const*) (in lib/libQt6Core.so.6.9.0)
==3769588== by 0x48975D8: QTest::compare_string_helper(char const*, char const*, char const*, char const*, char const*, int) (in lib/libQt6Test.so.6.9.0)
==3769588== by 0x12B12A: QTest::qCompare(char*, char*, char const*, char const*, char const*, int) (in tests/auto/corelib/text/qstringconverter/tst_qstringconverter)
==3769588== by 0x10EE94: tst_QStringConverter::invalidConverter() (in tests/auto/corelib/text/qstringconverter/tst_qstringconverter)
Amends c46ee7df57.
Pick-to: 6.7 6.5 6.2
Fixes: QTBUG-126107
Change-Id: I44265a5eb67e47a59fc8fffd17d64051657af529
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 9d5611dc97979dab1932b07f8cfab367c3872d24)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Found more issues:
- quint8 and qint8 (signed and unsigned char) actually match an
integral overload (probably int/uint), and _not_ (char),
- char8_t (only in C++20 builds) and (at least on non-Windows) wchar_t
are incorrectly treated as numeric types,
- qfloat16 breaks if QFLOAT16_IS_NATIVE.
Created a few tasks to track these.
Task-number: QTBUG-126053
Task-number: QTBUG-126054
Task-number: QTBUG-126055
Pick-to: 6.7 6.5 6.2
Change-Id: Iaf64929e3fae257d5dd283f555bb71ea2908cc94
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 967736b96ba06bfdfdf553b2c3720d7adc4a921c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This exercise found an inconsistency involving char16_t. Filed
QTBUG-125588 to keep track of this and decide how to deal with it.
Task-number: QTBUG-125588
Pick-to: 6.7 6.5
Change-Id: I259fecef34539e8841149570d7411d959b48d876
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Extending the fromCharacter() tests to check for the construction to
be noexcept and implicit turned up a few bugs:
The constructor from char32_t was simply not marked as noexcept, even
though all its operations were. So just mark it noexcept.
The constructor from QChar, otoh, was never called, (certainly not for
rvalues), because QString happens to be constructible from QChar (and
QLatin1Char and QChar::SpecialCharactor), so due to perfect
forwarding, the if_convertible_to<QString> ctor won, allocating a
QString.
This is a regression of Qt 6.5 compared to Qt 6.4.
To fix this, exclude arguments that convert to QChar from matching the
if_convertible_to<QString/QByteArray> ctors, taking care to not match
those arguments that are already compatible_char<>s.
This, in turn, creates a problem for implicit QASV construction from
QLatin1Char and QChar::SpecialCharacter, because now that we've
excluded them from the if_convertible_to<QString> ctor, calling the
existing QChar or QString non-template constructors for these types
would require two user-defined conversions (from said type to
QChar/QString and from QChar/QString to QAnyStringView). That works
for explicit construction, but we need implicit convertability.
So bring out the big guns once more and add a perfectly-forwarding
ctor for anything convertible to QChar. QChar itself is actually
already handled by compatible_char<>, so the old QChar non-template
ctor can go. The extra copy of the QChar argument will be optimized
away by the compiler.
[ChangeLog][QtCore][QAnyStringView] Fixed a regression where
constructing a QAnyStringView from a char-like type (QChar,
QLatin1Char, ...) would first construct a QString and only then
convert that to QAnyStringView.
Amends 812a0d3125.
This change is forward and backward BC and SC, but not
behavior-compatible: certain operations detectably change
noexcept'ness, and some arguments may now cause the resulting
QAnyStringView to have a different encoding (though I really tried
hard to avoid that).
Since it's a regression, I proposed to pick this to the affected
branches, 6.7 and 6.5 (6.6 is already closed at this point).
Pick-to: 6.7 6.5
Fixes: QTBUG-125735
Change-Id: I86f37df5d80bee36db27e529c017cb73995a6831
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
These were not covered by the existing tests.
Pick-to: 6.7 6.5 6.2
Change-Id: I909ea3aa5b676904dc72ecf8ce32b73cca1b6af7
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Add missing checks for integral overloads uint, short and ushort and
character overloads char and char16_t (the latter being a reproducer
for QTBUG-125588).
Pick-to: 6.7 6.5 6.2
Task-number: QTBUG-125588
Change-Id: I479e4c8c3cd86c3f85ab3c9d44b79158b0a48476
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Move the constexpr fromArray() check from fromArray() to constExpr()
and there add the protection necessary to work around
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71962, copied from
tst_QByteArrayView.
As a drive-by, add the test for constexpr construction from a char16_t
array, which was missing here (probably because of the GCC bug) while
the corresponding test was already in tst_QByteArrayView.
Amends 107ff4c1d6b5da2cb11c65b2bd9106817f7fdb02(!).
(iow: 6.0, and no, I don't know why it became a problem only now)
Pick-to: 6.7 6.5 6.2
Change-Id: Id9d2a08175709f8bf85b3b192e7aa49783b9e715
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Move the constexpr fromArray() check from fromArray() to constExpr()
where there is already the protection necessary to work around
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71962.
Amends bbe7570ddcc6fcce707a355b76d2d0024c44ea38(!).
(iow: 6.0, and no, I don't know why it became a problem only now)
Pick-to: 6.7 6.5 6.2
Change-Id: Id9d2a08175709f8bf85b3b192e7aa49783b9e714
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Because of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71962, and
because marking constExpr() as __attribute__((no_sanitize_undefined))
doesn't fix a thing, we opted to disable the triggering parts of
constExpr() from all GCC builds.
This is, of course, unfortunate, since it meaningfully reduces
compile-time coverage in the general case for a rather obscure build
type most won't ever use.
While GCC doesn't give us a predefined macro to check for in the .cpp
file, the cmake build system knows whether we use ubsan, so just
define a macro of our own.
As a drive-by, simplify GCC detection by using Q_CC_GCC_ONLY.
Amends de6a004bc5.
Pick-to: 6.7 6.5 6.2
Task-number: QTBUG-101307
Change-Id: I4be5bd103b9d2386b2ac9fd22e0c34f9c63fee04
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Overload set to be used in QUuid soon.
Pick-to: 6.7 6.5
Change-Id: I6f2c180bb7bb884d40f1691409e816405c3e5d47
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Since commit 91e70f23 introduced separator to uiLanguages(), the system
locale id still does not respect the separator parameter and hardcodes
dash as separator. Fixing this should make the format consistent.
Pick-to: 6.7
Change-Id: I1ab8edfa49117bdc9c4353228e73c2d1e5becffc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Moody Liu <mooodyhunter@outlook.com>
... mirroring the same change in QLatin1StringMatcher.
Task-number: QTBUG-117054
Change-Id: I8d1f4ed01ee75a51e3d99a165dbb35ae7dae5886
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Now developer build tests compile, but some are not working.
Functional fix will come later via separate tasks.
Task-number: QTBUG-122999
Change-Id: I70487b46c1b32ba4279cb02a4978e4f55ac0d310
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Replace class operators operator==(), operator!=() of
QRegularExpression to friend method comparesEqual() and
Q_DECLARE_EQUALITY_COMPARABLE macro.
Use QT_CORE_REMOVED_SINCE and removed_api.cpp to get rid of
current comparison methods and replace them with a friend.
Task-number: QTBUG-120304
Change-Id: Ib6fc83d29ad9bc710c2fdf32a3d60131fbf298b6
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Replace public friend operators operator==(), operator!=() of
QLocale to friend method comparesEqual() and
Q_DECLARE_EQUALITY_COMPARABLE macro.
Task-number: QTBUG-120304
Change-Id: I759ef08269abe3b40e0dce3fd408a86cc3f34857
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The QRegularExpression capture-by-name keys are currently QStringViews,
but are only ever used to compare them against a const char16_t*, so
this API is a perfect candidate for replacing all of these overload sets
with a single QAnyStringView function.
[ChangeLog][QtCore][QRegularExpression] Keys can now be passed as
QAnyStringView (was QStringView).
Fixes: QTBUG-103097
Change-Id: I1a80e85f301cc08370d70b3b5eb0ae10c6a51f33
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
I neglected to update the CLDR dateconverter code when I expanded the
range of forms we support for display of a timezone. Even that
expanded range doesn't cover all the cases CLDR does, but we can at
least approximate each of CLDR's options by the closest we do support.
Make matching changes to how the Darwin backend for the system locale
maps its ICU-derived formats to ours.
This in practice changes all locales previously using t (abbreviation)
as zone format to use tttt (IANA ID) instead. Test data updated to
match.
[ChangeLog][QtCore][QLocale] Date-time formats now more faithfully
follow the CLDR data in handling timezones. In most cases this means
the IANA ID is used in place of the abbreviation.
Change-Id: I0276843085839ba9a7855a78922cffe285174643
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There was a discrepancy that the multi-arg arg() overload would accept
any number of digits in the placeholder, resolving up to value 999
(e.g., %000001 was interpreted as placeholder #1), but the single-arg
arg() overload only supported exactly one or two digits. The single-arg
behavior was documented, so use it.
[ChangeLog][Important Behavior Changes] The QString::arg() overload
taking multiple QString-like arguments is now fixed to interpret
placeholders like the other arg() overloads: it will find at most two
digits after the '%' character. That is, the sequence "%123" is now
interpreted as placeholder #12 followed by character '3' (verbatim).
Pick-to: 6.7
Fixes: QTBUG-118581
Change-Id: I455fe22ef4ad4b2f9b01fffd17c767a948d41138
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Both qlocale_mac.mm and dateconverter.py were mapping the CLDR am/pm
indicator, 'a', to the Qt format token 'AP', forcing the indicator to
uppercase. The LDML spec [0] says:
May be upper or lowercase depending on the locale and other
options.
[0] https://www.unicode.org/reports/tr35/tr35-68/tr35-dates.html#Date_Field_Symbol_Table
We don't support the "other options" mentioned, but we can at least
(since 6.3) preserve the the locale-appropriate case, instead of
forcing upper-case. As such, this change is a follow-up to
commit 4641ff0f6a
Changes locale data, as expected, to use "Ap" in place of "AP" in
various formats in the time_format_data[] array.
[ChangeLog][QtCore][QLocale] Where CLDR specifies an am/pm indicator,
the case of the CLDR-supplied indicator is used, where previously
QLocale forced it to upper-case.
Change-Id: Iee7d55e6f3c78372659668b9798c8e24a1fa8982
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The LDML spec includes a 'b' pattern character which is like the 'a'
pattern, for AM and PM, but would rather use noon and midnight
indicators for those specific times. We don't support those and using
am/pm will be right enough of the time to be better than simply
discarding this option, if it ever gets used (which it currently
isn't), so treat as an alias for 'a'. No locale in CLDR currently uses
this.
CLDR also has a 'B' specifiers for "flexible day periods", including
things like "at night" and "in the day". At present only zh_Hant uses
'B'. As a result, this change only affects zh_Hant's formats for time
and datetime, which only zh_Hant_TW uses - zh_Hant_HK overrides them
to use am/pm markers and zh_Hant_MO inherits that from
zh_Hant_HK. Based on this and user feed-back, I've opted to treat 'B'
as another synonym of 'a'.
This removes an entry from the time_format_data[] table (it happened
to occupy one whole twelve-character row), causing many other locales'
offsets into that table to be shifted by 12. Only zh_Hant_TW has an
actual change to which entry in the table it uses.
Added a test-case.
[ChangeLog][QtCore][QLocale] CLDR's 'B' (flexible day period, e.g. "at
night" &c.) field, not currently supported, is now handled as a
synonym for the AM/PM field 'a', instead of leaving the B as literal
text. Only affects zh_TW at present.
Fixes: QTBUG-123872
Change-Id: I6ba008c0a048190bf7af8c7df7629a885b05804f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Pass the pointer to the current state, not a pointer to a pointer to it.
[ChangeLog][QtCore][QStringConverter] Fixed a bug involving moved
QStringEncoder/QStringDecoder objects accessing invalid state.
Amends 122270d6be.
Done-with: Marc Mutz <marc.mutz@qt.io>
Pick-to: 6.7 6.5
Change-Id: I70d4dc00e3e0db6cad964579662bcf6d185a4c34
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QVariant is rather big for passing by value; and no caller has any
further use for the QVariant it's passing in.
Pick-to: 6.7 6.5
Task-number: QTBUG-122619
Change-Id: I2751745e715aacfa8982ac97b4ae777fde5e88de
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Axivion (SV546) points out (based on a clazy "rule of three" that
might be rule of five by now) the lack of move and copy assignment and
construction. We don't want those anyway, so tell the compiler not to
create them.
Pick-to: 6.7 6.5
Task-number: QTBUG-122619
Change-Id: Ie951a2c3d60d76ad3448310d3f9bbda22190015b
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Wrap the call in QVERIFY.
tst_QTextStream::read0d0d0a was also faulty as it *never* opened
the file because of a broken path. Fix it with QFINDTESTDATA.
Change-Id: I61a8f83beddf098d37fda13cb3bfb4aaa4913fc5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Because they always were, but we never tested it.
Change-Id: I503c65ed41b90d710c651d879a4477965f2ef0d6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Check that all string-like types implement compareThreeWay() as a
(hidden) friend function.
This test revealed some problems: because QByteArrayView is implicitly
constructible from QLatin1StringView, the qCompareThreeWay() call
sometimes picked the compareThreeWay() overloads with QByteArrayView
instead of picking the "reversed" overloads that use QLatin1StringView.
This was leading to wrong results, because QByteArrayView is
interpreted as utf-8 data, not latin-1.
Explicitly add the missing compareThreeWay() and comparesEqual()
overloads.
Note that relational operators were never affected by this problem,
because in C++17 mode we explicitly generate the reversed versions,
and in C++20 mode the compiler does that for us.
Task-number: QTBUG-117661
Change-Id: Ia96af59c60ebf2fae6cf2a49231d6b6f401aceaa
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This reverts commit c23d3ca1f0.
Reason for revert: Update to Emscripten 3.1.50 has been merged.
Change-Id: Ie2082dcc2ee34a6d4e519c143037fda9678be234
Reviewed-by: Even Oscar Andersen <even.oscar.andersen@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
Then we will automatically handle invalid leading characters instead
of throwing away the whole sequence when it cannot be converted.
Added a test that was failing before.
Drive-by change: add a comment explaining why we
have the stack allocated buffer.
Task-number: QTBUG-118834
Change-Id: I647a58f2ba95e2e7ed4ea6a964d99ecc0c91fad3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Also extend unit-test to use new test helper functions.
Remove the now-redundant test for three-way comparison, because it is
covered by the test helper functions.
Task-number: QTBUG-117661
Change-Id: I242b560c281245e04e34353c80000a20998fc677
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Replace the existing friend relational operators with the macros.
Add the previously-missing relational opertors with QChar and char16_t.
This allows to remove the last dummy relational operators and the
macros to generate them in tst_qstringapisymmetry.
Because of a bug in libstdc++[0], we have to explicitly keep the
QBA vs QBA relational operators even in C++20 mode. This problem is
specific to QByteArray, because it is convertible to const void *.
[0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114153
Task-number: QTBUG-117661
Change-Id: Iac7f81cd3274331b7c7695a51803321b511361c0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Replace the existing friend relational operators with the macros.
Add the previously-missing QChar vs `const char *` relational operators.
These require out-of-line helper methods, because we need to interpret
the `const char *` array as utf-8.
The `const char *` relational operators cause ambiguities when
comparing QChar with 0 (previously it was only handled by the nullptr_t
overloads). As we have it in several places in our tests, I'd assume
that the users can also do it. To resolve the ambiguities, mark the
new relational operators as Q_WEAK_OVERLOADs.
This allows to remove the dummy QChar vs `const char *` relational
operators from tst_qstringapisymmetry, but at the same time requires
that we introduce new dummy operators for QByteArray vs char16_t
comparison. These will be fixed in a follow-up patch.
For QLatin1Char - convert to uchar before doing the comparison, to
match the behavior of QLatin1StringView and QChar. Extend QChar's
unit tests.
Task-number: QTBUG-117661
Change-Id: I9213fe05a5efdb96d48688f07bec9519f9887a77
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This allows to remove the dummy relational operators from
tst_qstringapisymmetry.
Task-number: QTBUG-108805
Change-Id: I7cb3154d6fcb571cafab6b318806f74bc8300448
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add QU8SV vs QSV, QU8SV vs QChar, and QU8SV vs char16_t relational
operators.
This allows to get rid of the dummy relational operators in
tst_qstringapisymmetry.
Task-number: QTBUG-117661
Change-Id: If95d7418efd13c505ed0e3bef748b86ff55e623a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The comparison with QStringView works as is, there is no need to add
explicit operators.
Add the missing relational operators with QUtf8StringView. Once it
is added, comparison of QString with u8"string literal" becomes
ambiguous, so explicitly add operators for `const char8_t*` as well.
This also makes the comparison with u8 string literals faster,
because it now uses a view instead of constructing a QString.
Adding QUtf8StringView overloads also makes comparison with
`const char *` ambiguous if QT_RESTRICTED_CAST_FROM_ASCII is defined.
To fix that, mark the overload as Q_WEAK_OVERLOAD. Luckily, we can
just use the third Attributes parameter of the macro for that.
Provide more unit-tests to cover the new relational operators.
Task-number: QTBUG-117661
Change-Id: I60d1f4ad7ea607472deeb5c250e62f2bb7019268
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use the comparison helper macros to replace the member relational
operators for comparison with QByteArray and const char *.
As QString and QByteArray are exported, we cannot simply remove the
inline methods, so wrap them into QT_CORE_REMOVED_SINCE.
Add relational operators with QByteArrayView.
Provide more unit-tests for the comparison with the byte array types.
This enables operator<=> for QString vs byte arrays in C++20 builds.
Task-number: QTBUG-117661
Change-Id: I305343e1b6c5d78b10f2976573db4e904ba6b44b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Replace the hidden friend relational operators with hidden friend
helper functions and comparison helper macros.
Provide more unit-tests for the updated types.
This enables operator<=> in C++20 builds.
Task-number: QTBUG-117661
Change-Id: I17329cd6422f272a435fc1da241203581eef7fbb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Even though undocumented, it's public API, doesn't hurt to carry
along, and improves compiler coverage in the test, so let's not remove
it.
Found in 6.7 API review
Amends 95e6fac0a5.
Pick-to: 6.7
Change-Id: Ia935036a69e0e678f22ac86b48a2c1c5e8c46733
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Both QByteArrayView and std::string_view are Literal Types, so the
conversion between them should be constexpr.
Amends 96d67da420.
Found in API-review.
Pick-to: 6.7
Change-Id: Ic513ce32aa2a743ca890dc05a683a62c0f3a7d50
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
[ChangeLog][QtCore][QString/QByteArray] Added slice() methods that work
like sliced(), but modify the string/byte-array they are called on.
Task-number: QTBUG-99218
Change-Id: I3075562983ef123d9aa022a2304c7e774cf2ea42
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change type of variables `int` -> `size_t`, to match assigned value.
Fixes: QTBUG-122300
Change-Id: I5b99bd6a3b307ba2ec4ef79bcc517da60ae36413
Reviewed-by: Matthias Rauter <matthias.rauter@qt.io>
Now when QLatin1StringView implements relational operators with
QByteArrayView in terms of new comparison helper macros and helper
methods taking QByteArrayView, we can easily re-use these helper
methods to provide comparison with QByteArray and const char *.
QLatin1StringView already provided almost all of these operations,
partly as hidden friend functions, partly as inline methods.
Since the class is not exported, and the methods were inline, we
can just remove all of them and replace them with the comparison
helper macros.
This should speed up the relational operators, because they do not
construct string objects using QString::fromUtf8() anymore, but use
QUtf8StringView instead.
This also adds the previously missing QByteArray vs QLatin1StringView
relational operators.
Task-number: QTBUG-117661
Change-Id: I17a9185127ae130dab9409c6340a58f5d39f5a10
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... 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>
... by using the new comparison helper macros.
Also, convert the existing QByteArrayView relational operators to use
these macros.
An attempt to define the helper functions comparesEqual() and
compareThreeWay() as hidden friends leads to compilation errors, because
the QByteArrayView(QLatin1StringView) constructor gets somehow disabled.
Apparently, it cannot satisfy the
QtPrivate::IsContainerCompatibleWithQByteArrayView trait anymore.
I could not find a reason for that, so I just defined the helper
functions as static inline private members of QByteArrayView. This fixes
the issue.
This allows to enable related tests in tst_qstringapisymmetry.
Task-number: QTBUG-108805
Change-Id: I35a69e99db8c61531ec726dab5b242b857f69e85
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... by using the new comparison helper macors.
This allows to enable related tests in tst_qstringapisymmetry.
Task-number: QTBUG-108805
Change-Id: I2cef8f4a25889b74a921fea47995d59c3a49d368
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... by using the new comparison helper macros.
First the relational operators between QU8SV and QBAV where added,
and this resulted in the ambiguities when comparing QU8SV vs QBA.
So, the relational operators between QU8SV and QBA are also added
in the same commit. This, in turn, resulted in ambiguities when
comparing QU8SV and const char *, so add these relational operators
as well.
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: If7919496fdf4519fd2a9398397a39210aadba077
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... by using the new comparison helper macros.
The operators are marked as QT_ASCII_CAST_WARN, like the pre-existing
relational operators with QByteArray and const char *.
This allows to enable related tests in tst_qstringapisymmetry.
Task-number: QTBUG-117661
Task-number: QTBUG-108805
Change-Id: Ic9bcddffc25585edb7375c3e651d49d040a60454
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Marc Mutz
Thiago Macieira
Kirikaze Chiyuki
Ahmad Samir
Jari Helaakoski
Tatiana Borisova
Matthias Rauter
Edward Welbourne
Fabian Kosmale
Giuseppe D'Angelo
Ivan Solovev
Piotr Wierciński
Mårten Nordheim
Isak Fyksen