Like QStringView's, these classes' documentation promised
is_constructible<View,Char[]>, but failed to deliver, because neither
the (const Pointer&) nor the (const Container &) compile for arrays of
unkonwn bounds, and the (const Char*) one is just a QDoc fake.
Apply the same fix as for QStringView: Add a ctor specifically for
arrays of unknown bound, delegating to the (ptr) overload.
The GHS compiler doesn't like the CanConvert static_asserts, so
comment them out for it. The functionality itself is tested by
the from*ArrayWithUnknownSize tests.
[ChangeLog][QtCore][QUtf8StringView/QAnyStringView] Made construction
from arrays of unknown size compile. Such arrays will use the const
Char* constructor, determining the size of the array at runtime.
Pick-to: 6.5
Fixes: QTBUG-112746
Change-Id: I7acdcae3c5bdf80a0bed673e621d53ef34a92a1e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 734bd05d0a6d37d6488cf8d1b2b9f79b9329d966)
(cherry picked from commit 51bfc9da41faa41a3161d30879b394a0dac94dcf)
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
This is supposed to work, so check it.
Conflict resolutions for 6.8:
- added missing qspan.h include
Change-Id: I201033656f123b09644e5de447cd5d7b038e5155
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 8a3ffe7044249bcfb5185bd87a9713685d48de7b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 9bcbeea2adeda6b23b030a18af04fce9bf7e5998)
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Adding it here since this test case already has all the infrastructure
for the overload test.
Pick-to: 6.5
Change-Id: I2d7fff9d2d82fed3db2446690a354f939c9a37fc
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 140dac92f2a8ee1f54843f69be4026900a049ee7)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 29e269567610aff4e26738aff507e58e23900133)
Other view tests test Char[N] and const Char[N] separately. Do the
same here.
For many Char types, the array CanConvert test was missing
completely. Add them.
Pick-to: 6.5
Change-Id: I1d0b6de394d548554a547f190e74cb8cead6ecd4
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 0bbbbfc78beb2393ceea0de0fa85942f71d0a2ed)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 443bdb96206a66159ccd07e0704015cf07321327)
The QtDeclarative code causing QTBUG-131906 hits UB, because it tries
to store -666 in an enum {A, B}, which has a valid range of [0,1],
therefore its underlying_type is uint, yet, as per [conv.prom]/3¹,
integer-promotes to _int_ instead, so in Qt 6.8 would cause the
arg(int) overload to be called, outputting -666, while in Qt 6.9, it's
treated (correctly) as an unsigned value, outputting -666's two's
complement, a positive value.
Add a version of the scenario that does not cause UB.
¹ Thanks to Ahmad Samir for digging up the pertinent legalese.
Task-number: QTBUG-131906
Pick-to: 6.5
Change-Id: Iba1a04de523a0b4cd1c87deea40c643cf16df14f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit e64fd05fecae291c9d7358d2e47d7170995af256)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 06a209384aff389af1b73cc77266f9b392219845)
They are not.
Task-number: QTBUG-112746
Change-Id: I2a20d68543f5914690acbcb4f214b1d98681de6a
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
(cherry picked from commit 67990c16a6b631c1d809d1ad656fc941293b3f83)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 31e30122963796d454d0351da92b0a608f305e50)
The original idea (8b5aa7b6c4) of the
separation of array and pointer ctors was to determine string literal
sizes at compile-time in C++11's limited constexpr semantics.
But when the scanning for NUL characters was added to the array ctor
in 107ff4c1d6, the distinction between
the two ctors became meaningless, because we were able to assume
post-C++11 constexpr to make the Char(0) scan a compile-time action.
Finally, 9e1dc1e8a9 removed the array
ctor in favor of the generic Container ctor. I didn't check whether
the old code handled arrays of unknown size, as in
extern const char16_t str[];
QStringView sv = str;
~~~
const char16_t str[] = "str";
but std::size() (and therefore if_compatible_container) surely bails
on such arrays, and if_compatible_pointer also SFINAEs out. As a
consequence, such arrays cannot be used to construct QStringViews atm.
Fix by adding a new constructor for arrays of unknown size, delegating
to the existing pointer overload.
The GHS compiler doesn't like the CanConvert static_asserts, so
comment them out for it. The functionality itself is tested by
the from*ArrayWithUnknownSize tests.
[ChangeLog][QtCore][QStringView] Made construction from arrays of
unknown size compile. Such arrays will use the const Char*
constructor, determining the size of the array at runtime.
Pick-to: 6.5
Task-number: QTBUG-112746
Change-Id: Ifdb217350d93d38f081c99f14661975491d32076
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 56faffd92bf0ac459a921ec043a6f3b3dba51acc)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 2dfc0cb6f6f1e29a0a1318793b29b89390543be6)
QChar[N] and ushort[N] are being checked, it's unclear why char16_t[N]
and wchar_t[N] were missing.
Add them.
Pick-to: 6.5 5.15
Change-Id: I9a2df2a75886b950e8c2bdec843e3e693e536f86
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 89401858696d63b8a13c945d5db63856a3b6f5ba)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 67adc2227dc179828d01475c2b9e534bca3152b7)
It can (unlike the other views).
Pick-to: 6.5 5.15
Task-number: QTBUG-112746
Change-Id: Id976429611c53f1c707de1d989c454507b8f4773
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 01f0305dc6f751d3eb4d1681a2f8f9f3165b547c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 0c054f6844583136f19608526b0319735d66f0b8)
The lack of this was hidden by other rules (redundant with it) until
CLDR v45, but v46 prunes the redundant rules, breaking this. So
include the missing rule and tweak the code that assumed likely
sub-tag rules preserved language, since this one doesn't. Rework the
tail of withLikelySubtagsAdded() to correctly use this rule, now that
we have it. (The prior comment about there being no match-all was
wrong: CLDR did have it, but our data skipped it.) Amended one test
affected by it (when system locale wasn't en_US).
On picking to 6.8, uiLanguages() needed some coaxing to avoid
duplicate C locale entries in tests of qualified C locale.
Task-number: QTBUG-130877
Change-Id: I2a415b67af4bc8aa6a766bcc1e349ee5bda9f174
Reviewed-by: Mate Barany <mate.barany@qt.io>
(cherry picked from commit 303863170c3ea7d1ee1b7188f507ad432ed3f860)
Conflict resolution for 6.8:
- remove the QEXCEPT_FAIL - 6.8 was never affected
Task-number: QTBUG-131906
Pick-to: 6.5
Change-Id: Icdd647bf6a36ad11e6e19786121d25392b53236c
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 64daf773afff7dbe440621a57f015d985e41f84a)
Those files are read by reuse to complement or override the copyright
and licensing information found in file.
The use of REUSE.toml files was introduced in REUSE version 3.1.0a1.
This reuse version is compatible with reuse specification
version 3.2 [1].
With this commit's files,
* The SPDX document generated by reuse spdx conforms to SPDX 2.3,
* The reuse lint command reports that the Qt project is reuse compliant.
[1]: https://reuse.software/spec-3.2/
Task-number: QTBUG-124453
Task-number: QTBUG-125211
Change-Id: I01023e862607777a5e710669ccd28bbf56091097
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 4c83657448f66ac0ee46900aff2e5a230eda49b0)
Like QString, QChar also changes API when said macro is defined.
So, like tst_QString from 8420d3e0b2
onwards, also compile tst_QChar under it, separately.
Pick-to: 6.5
Change-Id: I81d25d5bfae78b1a11d47e49aa618d079c4b09b7
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 167b04aac89488a5f2005bd1f4dfde354f43c6a6)
As usual, when making a change, we find out that test coverage was
poor. Add such tests for QChar ctors.
Amends (should have been a prequel commit of)
9ef4c123c39c642357c9e8530d59f32f220a7824.
Conflict resolution for 6.8:
- adjusted static_asserts to old QChar ctor overload set
Pick-to: 6.5 6.2 5.15
Change-Id: Idcd9ab816ef815ce4a85dba1f7e37201b64c2203
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
(cherry picked from commit 69190a370d1e9f60c78f3096df62a61b6a5d1384)
In tst_qlocale.cpp there was a #include that caused the static data
tables to be duplicated, violating ODR. All it actually needed was the
ability to iterate all rows of the locale_data[] table, so export a
method to do that from QLocaleData and have the test run that instead
of pulling in a second copy of the tables.
Conflict resolution at 6.8 needed the declaration of locale_data_size
moved up qlocale.cpp, which happened after 6.8 as part of other work
that isn't included in 6.8.
Pick-to: 6.5 6.2
Task-number: QTBUG-128930
Change-Id: Ie5ebdf508a622eeca93f8785bc09b086502aa0e2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 96c07655c46afdd3e2da7ef7d339b518d36c83c5)
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
We do have an implicit constructor which allows construction of a
QLocale from the QLocale::Language enum values. It will be used when
doing the comparison.
However, do not rely on the implicit conversions, and provide the
operators that explicitly do the right thing. This also allows us to
save an extra allocation of QLocalePrivate.
Found in Qt 6.8 API review.
Amends 71bbc35a37.
As a drive-by: fix the order of the test slots in the unit test.
Change-Id: I37f8f5881469b7734705e06e471746814dd2ddf0
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 403b1abcad5f437c51dfabd7095b814e99e197a1)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Methods with preconditions can't be noexcept (from Marc in code
review).
[ChangeLog][QtCore][String Views] Added slice() methods to
Q{String,ByteArray,Latin1String,Utf8String,AnyString}View which work
like sliced() but modify the view they are called on.
Found in API review.
Task-number: QTBUG-99218
Change-Id: Ic8ef3085f7cfac86b8404fb28d491ca38ad121eb
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit 8f68bd9e6353a42d3b71d893b27fec6bedced501)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Complements ab05e05f60253b9be615c09aa340ee75f2e5bcaf:
Strings: get rid of the last std::char_traits use
LLVM's libc++ became pedantic and insists on only accepting
instantiations for one of the standard Char types, so remove all uses of
it with a template parameter.
Complements dc2ae08e02.
which is:
QStringView: stop instantiating std::char_traits<QChar> and <uchar>
It's deprecated and will be removed with LLVM 19.
Amends b1ee49b465.
Fixes: QTBUG-128325
Task-number: QTBUG-126214
Task-number: QTBUG-122753
Pick-to: 6.7
Change-Id: I2c7fbe3c0f557e98e7edfffdb00b4cc71a6612ca
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
(cherry picked from commit b387537d3e9c35d9f112d4aa32ad71df5e5e9028)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
By using {QString,QByteArray}::begin() instead of data() (for const
objectst); both begin() methods, respectively [1], return nullptr for a
const null {QString,QByteArray}. Whereas data() returns &_empty if
QT5_NULL_STRINGS is defined.
[1] QByteArray::begin() since a116b2ddfc
QString::begin() since 287ace562e
[ChangeLog][QtCore][QLatin1StringView] Creation of QLatin1StringView
from QByteArray or QByteArrayView now preserves the origin's isNull()
status. This matches the behavior of creating a QUtf8StringView from
those types.
Change-Id: Icbdfe282e315c08ca6a17201bcd32c1a3bba8bf5
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 221d8fdfb14c16472267320f859105f1a3834952)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
It's failing to produce output in reasonable time and blocking the CI.
Since this test is basically a syntax checker, it not being present for
WASM is not a great loss.
Task-number: QTBUG-128322
Change-Id: Ic49e7523af63d5819c13fffdd7a752534b77f0ab
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit f414505eaac5c222fc6404b9cda24fec25f68a7a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
lastIndexOf will convert the `needle` to unsigned char, which is then
'upcast' to int, before we search. But the string itself was searched
using signed char, meaning any values with the signed bit set would
mismatch.
Add tests for indexOf and lastIndexOf.
Amends 4c12ae7e67
Fixes: QTBUG-128199
Change-Id: I0ce7d7d9741f21650ef6f0f012a94e00d84a0f02
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 7b1f3bdc503ea7aceacc9fa8d388d843f1d7b131)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The qsnprintf() function introduces even more platform variability
than std::snprintf(), so from now on, we're using only std::snprintf().
Task-number: QTBUG-127110
Change-Id: Ic81b2a760521d77442cc328d2cfa7659bba8b7e2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit b8a956c2d3f9c158594265eca89185bd2bc671e7)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When converting a wildcard into a regexp, convert a series of
consecutive '*' tokens in just one '.*' (instead of a series of '.*').
The pattern matched is the same, but we reduce the effects of a
possible catastrophic backtracking. I'm not actually sure whether
PCRE optimizes this case out of its own or it doesn't; Perl appears
not to.
Change-Id: Ia83336391593d56cf6d8332c96649a034a83a15b
Fixes: QTBUG-127672
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit a041cd35214e57a189aaa1f1f77199ff42303f83)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
They were lacking it since the start of the public history, and
porting to std::snprintf() (which has the warning) as part of making
Qt compile with QT_NO_SNPRINTF has turned up surprisingly many
-Wformat warnings, so enable the warning for the remaining (non-tree)
users.
Backporting aggressively, as this might unearth security bugs in user
code.
[ChangeLog][QtCore][q(v)snprintf] Added attributes for GCC-compatible
compilers to detect format/argument mismatches. If this throws warnings
for your calls now, don't ignore them. printf() format mistakes could
be security-relevant. You may also find that you relied on undocumented
behavior, such as that certain implementations (Windows, Android, WASM)
of qsnprintf() support char16_t* instead of wchar_t* for %ls. In that
case, you should port to qUtf16Printable() and QString::asprintf(), or
suppress the warning and port away from the platform dependence at your
earliest convenience.
Task-number: QTBUG-127110
Pick-to: 6.7 6.5 6.2 5.15
Change-Id: I5c1fd9b2d5d2d55c68773f33edfd76acacd2408c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Jason McDonald <macadder1@gmail.com>
(cherry picked from commit 64416d3cf645187385d8ad90bc44d9c8e9ce864f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
... it is. Filed QTBUG-125730 to track this and discuss how to deal
with it.
Pick-to: 6.7 6.5 6.2
Task-number: QTBUG-125730
Change-Id: I2c680e1a9e8dda43700468a544ac645e1fa3aa53
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 3ff55648cee8365fb7825ca7a038596b63757ea3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This was in fact present in v44, but we overlooked it somehow. The new
version also fixes some inconsistencies in the data, that I reported
against v44.1; in particular, Tamil no longer claims to override the
root AM/PM markers (probably because it uses 24-hour time so doesn't
need them).
Add the test-file under util to the list of files containing generated
content.
Conflict at 6.8 resolved by regenerating the data; this only changed
the date of generation, not the data. Then hand-edited the date to
match the picked upstream commit, to avoid future conflicts.
[ChangeLog][Third-Party Code] Updated CLDR data, used by QLocale, to
v45.
Task-number: QTBUG-126060
Pick-to: 6.7 6.5 6.2
Change-Id: I81a5bcca49519b55091fc541de6b73b606661bb4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit f79548e268a496698d77d0e78365334d0e507212)
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The build on Android with clang results in a bunch of irrelevant
warnings. Disable them for the offending lines of test code.
Change-Id: Ica5d867e3a2b1215dc526cc5f945a39ac908ac23
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 8d523a098cc8068400a6138970c6382f8f56224c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The "many-0 max dec" tests check if a large number (512) of leading zeros
interferes with parsing the number.
The std::from_chars implementation available on VxWorks cannot handle
strings longer than 255 characters.
The number is properly parsed, but the ptr returned as a part of the
std::from_chars_result does not contain the correct result.
It should point to the end of the string (as there is nothing left after the
number), but it wraps and starts to point to other places.
This leads to a wrong value returned by qstrnto(u)ll and to a failing
test.
The issue has been acknowledged by WindRiver. For now, blacklist the
"many-0 max dec" tests.
Pick-to: 6.7
Task-number: QTBUG-115777
Change-Id: I0a897728c71503e6817c69f8ced8ebb0a45295af
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit aea27282b783059ef52e928e811029cedb98ebf9)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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>
Marc Mutz
Edward Welbourne
Lucie Gérard
Mårten Nordheim
Ivan Solovev
Ahmad Samir
Thiago Macieira
Giuseppe D'Angelo
Volker Hilsheimer
Albert Astals Cid
Łukasz Matysiak
Tatiana Borisova
Kirikaze Chiyuki
Jari Helaakoski