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>
I've reserved the IDs for int128, uint128, bfloat16, and float128,
because the mask in qvariant.cpp's qIsNumericType() requires primitives
to be less than 64 to operate properly.
Added a QMetaType/QDataStream test to confirm it is indeed built-in.
Change-Id: I3d74c753055744deb8acfffd17247f7f57bada02
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The C++ equivalent is std::float16_t, defined in P1467[1], and is coming
with GCC 13 both in native mode (for x86, using AVX512FP16) and in
emulated mode. The C and C++ types will be the same type (<stdfloat>
simply typedefs).
qfloat16 will need to remain a wrapper with an integer member to keep
ABI with previous Qt versions. Because it is a trivially-copyable small
type, it gets currently passed in registers; the presence of the integer
member means it gets passed in general-purpose registers, while a single
_Float16 member would be passed in a floating-point register. See:
https://gcc.godbolt.org/z/8fEendjff
[1] https://wg21.link/p1467
Change-Id: I8a5b6425b64a4e319b94fffd161be56397cb48e6
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
... where checks for QByteArray existed before.
The checks we can't add are
- left/right/mid (legacy APIs not implemented in QBAV)
- several relational operators, d/t ambiguities. Created
QTBUG-108805 to track these.
Task-number: QTBUG-108805
Pick-to: 6.4 6.2
Change-Id: I30cc9b29a228d69d32af51234f2c28221478a75c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
It's not intuitive, so check lest people break it.
Pick-to: 6.4 6.2
Change-Id: I2435cd69be7b77a6ae59cdc7b5fb99658cfc42fd
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Underflows should be treated the same as overflows.
Fixes: QTBUG-108628
Change-Id: I23aa7bbe1d103778cefca08bd3e584e72f306583
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Rework QSimpleParsedNumber to store a qsizetype whose sign serves as
ok flag (positive is ok, zero and negative are not) and magnitude is
the number of characters used. This replaces an endptr that was set to
null to indicate !ok, but that deprived us of end-of-parse
information, which is needed for number-parsing. In particular, JS's
parsing of numbers accepts overflow (where qstrntod() flags it as
invalid) as infinity; so qstrntod() does need to say how long the
overflowing (but JS-valid, none the less) number-text was.
Modify all callers of functions using this (recently-introduced) type
and add tests that fail without this fix.
Fixes: QTBUG-108628
Change-Id: I416cd213e1fb8101b1af5a6d43615b970a5db9b4
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
- If this string is not shared, modify it directly
- If this string is shared, instead of detaching copy the characters
from this string, except the ones that are going to be removed, to a
new string and swap it. This is more efficient than detaching, which
would copy the whole string including the characters that are going
to be removed.
This affects:
remove(const QString &str, Qt::CaseSensitivity cs)
remove(QLatin1StringView str, Qt::CaseSensitivity cs)
Adjust the unittests to test both code paths.
[ChangeLog][QtCore][QString] Improved the performance of
QString::remove() by avoiding unnecessary data copying. Now, if this
string is (implicitly) shared with another, instead of copying
everything and then removing what we don't want, the characters from
this string are copied to the destination, except the ones that need to
be removed.
Task-number: QTBUG-106181
Change-Id: Id8eba59a44bab641cc8aa662eb45063faf201183
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This tests that strings using the first Unicode code-point of such a
multi-character token don't get recognized as "valid" number strings.
This would catch an implementation issue if the parsing code
mistakenly matched against only the first code-point of each "single
character" token.
It also adds tests of integer formatting, with multi-character sign,
and reworks some QStringView().toString()s to use u"..."_s.
Task-number: QTBUG-107801
Change-Id: I7b868ce2955bb322b3ecfc200438a21437090a0c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Most of them were easy to change. The pair one was a bit of a stretch,
but still worked. I've removed the lines on QPair, since QPair is
std::pair in Qt 6.
Change-Id: I3d74c753055744deb8acfffd17246ec98c583d08
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
qIsNumericType does not return true for enum types, which meant we never
called numericCompare() or numericEquals() when one of the types was an
enum.
Task-number: QTBUG-108188
Change-Id: I3d74c753055744deb8acfffd172449c68af19367
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The code implementing the C++ rules of type promotion and conversion
was too pedantic. There's no need to follow the letter of the standard,
not when we can now assume that everything is two's complement (this was
true for all architectures we supported when I wrote this code in 2014,
but wasn't required by the standard).
So we can reduce this to fewer comparisons and fewer rules, using the
size of the type, not just the type ID.
Change-Id: I3d74c753055744deb8acfffd172446b02444c0c0
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The insets used to calculate the correct height were not the best
choice. It used display cutout insets which would work correctly on
most devices, but in the case of an emulator or a device without a
camera, it could fail to calculate correctly.
Task-number: QTBUG-107604
Task-number: QTBUG-107709
Task-number: QTBUG-107523
Pick-to: 6.4 6.4.1 6.2 5.15
Change-Id: I8c4da83ae7359a0c133dbeb02dbd2cd260565f78
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Basic unitttest and one to verify erase returns iterator, not
const_iterator.
Change-Id: I44c3b82b4686ff3809648063376f5e36fb7e181d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- If the string isn't shared, don't call detach(), instead remove characters
matching ch, and resize()
- If the string is shared, create a new string, and copy all characters
except the ones that would be removed, see task for details
Update unittets so that calls to this overload of remove() test both code
paths (replace() calls remove(QChar, cs) internally).
Drive-by change: use QCOMPARE() instead of QTEST()
Task-number: QTBUG-106181
Change-Id: I1fa08cf29baac2560fca62861fc4a81967b54e92
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- If this bytearray isn't shared call d->erase() as needed
- if it's shared, instead of detaching, create a new bytearray, and copy
all characters except for the ones that would be removed
See task for details.
Adjust unittest to test both code paths.
Task-number: QTBUG-106182
Change-Id: I806e4d1707004345a2472e056905fbf675f765ab
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is a semantic patch using ClangTidyTransformator as in
qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8, but extended to
handle typedefs and accesses through pointers, too:
const std::string o = "object";
auto hasTypeIgnoringPointer = [](auto type) { return anyOf(hasType(type), hasType(pointsTo(type))); };
auto derivedFromAnyOfClasses = [&](ArrayRef<StringRef> classes) {
auto exprOfDeclaredType = [&](auto decl) {
return expr(hasTypeIgnoringPointer(hasUnqualifiedDesugaredType(recordType(hasDeclaration(decl))))).bind(o);
};
return exprOfDeclaredType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))));
};
auto renameMethod = [&] (ArrayRef<StringRef> classes,
StringRef from, StringRef to) {
return makeRule(cxxMemberCallExpr(on(derivedFromAnyOfClasses(classes)),
callee(cxxMethodDecl(hasName(from), parameterCountIs(0)))),
changeTo(cat(access(o, cat(to)), "()")),
cat("use '", to, "' instead of '", from, "'"));
};
renameMethod(<classes>, "count", "size");
renameMethod(<classes>, "length", "size");
except that the on() matcher has been replaced by one that doesn't
ignoreParens().
a.k.a qt-port-to-std-compatible-api V5 with config Scope: 'Container'.
Added two NOLINTNEXTLINEs in tst_qbitarray and tst_qcontiguouscache,
to avoid porting calls that explicitly test count().
Change-Id: Icfb8808c2ff4a30187e9935a51cad26987451c22
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
- If this string isn't shared, don't call detach, instead use ->erase() as
needed
- If this string is shared, create a new string, and copy all elements
except the ones that would be removed, see task for details
Update unittest to test both code paths.
Task-number: QTBUG-106181
Change-Id: I4c73ff17a6fa89ddcf6966f9c5bf789753f6d39e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
With the introduction of QAnyStringView, overloading based on UTF-8
and Latin-1 is becoming more common. Often, the two overloads can
share the processing backend, because we're only interested in the
US-ASCII subset of each.
But if they can't, we need a faster way to convert L1 into UTF-8 than
going via UTF-16. This is where the new private API comes in.
Eventually, we should have the converse operation, too, to complete
the set of direct conversions between the possible three
QAnyStringView encodings L1/U8/U16, but this direction is easier to
code (there are no error cases) and more immediately useful, so
provide L1->U8 alone for now.
Change-Id: I3f7e1a9c89979d0eb604cb9e42dedf3d514fca2c
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Borrowed from tst_qtemporaryfile with some changes.
Change-Id: I596ddd0ac8dbe10edd63e481198064dcec15d3e6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
qhashfunctions.h defines a catch-all 2-arguments qHash(T, seed)
in order to support datatypes that implement a 1-argument overload
of qHash (i.e. qHash(Type)). The catch-all calls the 1-argument
overload and XORs the result with the seed.
The catch-all is constrained on the existence of such a 1-argument
overload. This is done in order to make the catch-all SFINAE-friendly;
otherwise merely instantiating the catch-all would trigger a hard error.
Such an error would make it impossible to build a type trait that
detects if one can call qHash(T, size_t) for a given type T.
The constraint itself is called HasQHashSingleArgOverload and lives in a
private namespace.
It has been observed that HasQHashSingleArgOverload misbehaves for
some datatypes. For instance, HasQHashSingleArgOverload<int> is actually
false, despite qHash(123) being perfectly callable. (The second argument
of qHash(int, size_t) is defaulted, so the call *is* possible.)
--
Why is HasQHashSingleArgOverload<int> false?
This has to do with how HasQHashSingleArgOverload<T> is implemented: as
a detection trait that checks if qHash(declval<T>()) is callable.
The detection itself is not a problem. Consider this code:
template <typename T>
constexpr bool HasQHashSingleArgOverload = /* magic */;
class MyClass {};
size_t qHash(MyClass);
static_assert(HasQHashSingleArgOverload<MyClass>); // OK
Here, the static_assert passes, even if qHash(MyClass) (and MyClass
itself) were not defined at all when HasQHashSingleArgOverload was
defined.
This is nothing but 2-phase lookup at work ([temp.dep.res]): the
detection inside HasQHashSingleArgOverload takes into account the qHash
overloads available when HasQHashSingleArgOverload was declared, as well
as any other overload declared before the "point of instantiation". This
means that qHash(MyClass) will be visible and detected.
Let's try something slightly different:
template <typename T>
constexpr bool HasQHashSingleArgOverload = /* magic */;
size_t qHash(int);
static_assert(HasQHashSingleArgOverload<int>); // ERROR
This one *does not work*. How is it possible? The answer is that 2-phase
name lookup combines the names found at definition time with the names
_found at instantiation time using argument-dependent lookup only_.
`int` is a fundamental type and does not participate in ADL. In the
example, HasQHashSingleArgOverload has actually no qHash overloads to
even consider, and therefore its detection fails.
You can restore detection by moving the declaration of the qHash(int)
overload *before* the definition of HasQHashSingleArgOverload, so it's
captured at definition time:
size_t qHash(int);
template <typename T>
constexpr bool HasQHashSingleArgOverload = /* magic */;
static_assert(HasQHashSingleArgOverload<int>); // OK!
This is why HasQHashSingleArgOverload<int> is currently returning
`false`: because HasQHashSingleArgOverload is defined *before* all the
qHash(fundamental_type) overloads in qhashfunctions.h.
--
Now consider this variation of the above, where we keep the qHash(int)
overload after the detector (so, it's not found), but also prepend an
Evil class implicitly convertible from int:
struct Evil { Evil(int); };
size_t qHash(Evil);
template <typename T> constexpr bool HasQHashSingleArgOverload = /* magic */;
size_t qHash(int);
static_assert(HasQHashSingleArgOverload<int>); // OK
Now the static_assert passes. HasQHashSingleArgOverload is still not
considering qHash(int) (it's declared after), but it's considering
qHash(Evil). Can you call *that* one with an int? Yes, after a
conversion to Evil.
This is extremely fragile and likely an ODR violation (if not ODR, then
likely falls into [temp.dep.candidate/1]).
--
Does this "really matter" for a type like `int`? The answer is no. If
HasQHashSingleArgOverload<int> is true, then a call like
qHash(42, 123uz);
will have two overloads in its overloads set:
1) qHash(int, size_t)
2) qHash(T, size_t), i.e. the catch-all template. To be pedantic,
qHash<int>(const int &, size_t), that is, the instantiation of the
catch-all after template type deduction for T (= int)
([over.match.funcs.general/8]).
Although it may look like this is ambiguous as both calls have perfect
matches for the arguments, 1) is actually a better match than 2) because
it is not a template specialization ([over.match.best/2.4]).
In other words: qHash(int, size_t) is *always* called when the argument
is `int`, no matter the value of HasQHashSingleArgOverload<int>. The
catch-all template may be added or not to the overload set, but it's
a worse match anyways.
--
Now, let's consider this code:
enum MyEnum { E1, E2, E3 };
qHash(E1, 42uz);
This code compiles, although we do not define any qHash overload
specifically for enumeration types (nor one is defined by MyEnum's
author).
Which qHash overload gets called? Again there are two possible
overloads available:
1) qHash(int, size_t). E1 can be converted to `int` ([conv.prom/3]),
and this overload selected.
2) qHash(T, size_t), which after instantiation, is qHash<MyEnum>(const
MyEnum &, size_t).
In this case, 2) is a better match than 1), because it does not require
any conversion for the arguments.
Is 2) a viable overload? Unfortunately the answer here is "it depends",
because it's subject to what we've learned before: since the catch-all
is constrained by the HasQHashSingleArgOverload trait, names introduced
before the trait may exclude or include the overload.
This code:
#include <qhashfunctions.h>
enum MyEnum { E1, E2, E3 };
qHash(E1, 42uz);
static_assert(HasQHashSingleArgOverload<MyEnum>); // ERROR
will fail the static_assert. This means that only qHash(int, size_t) is
in the overload set.
However, this code:
struct Evil { Evil(int); };
size_t qHash(Evil);
#include <qhashfunctions.h>
enum MyEnum { E1, E2, E3 };
qHash(E1, 42uz);
static_assert(HasQHashSingleArgOverload<MyEnum>); // OK
will pass the static_assert. qHash(Evil) can be called with an object of
type MyEnum after an user-defined conversion sequence
([over.best.ics.general], [over.ics.user]: a standard conversion
sequence, made of a lvalue-to-rvalue conversion + a integral promotion,
followed by a conversion by constructor [class.conv.ctor]).
Therefore, HasQHashSingleArgOverload<MyEnum> is true here; the catch-all
template is added to the overload set; and it's a best match for the
qHash(E1, 42uz) call.
--
Is this a problem? **Yes**, and a huge one: the catch-all template does
not yield the same value as the qHash(int, size_t) overload. This means
that calculating hash values (e.g. QHash, QSet) will have different
results depending on include ordering!
A translation unit TU1 may have
#include <QSet>
#include <Evil>
QSet<MyEnum> calculateSet { /* ... */ }
And another translation unit TU2 may have
#include <Evil>
#include <QSet> // different order
void use() {
QSet<MyEnum> set = calculateSet();
}
And now the two TUs cannot exchange QHash/QSet objects as they would
hash the contents differently.
--
`Evil` actually exists in Qt. The bug report specifies QKeySequence,
which has an implicit constructor from int, but one can concoct infinite
other examples.
--
Congratulations if you've read so far.
=========================
=== PROPOSED SOLUTION ===
=========================
1) Move the HasQHashSingleArgOverload detection after declaring the
overloads for all the fundamental types (which we already do anyways).
This means that HasQHashSingleArgOverload<fundamental_type> will now
be true. It also means that the catch-all becomes available for all
fundamental types, but as discussed before, for all of them we have
better matches anyways.
2) For unscoped enumeration types, this means however an ABI break: the
catch-all template becomes always the best match. Code compiled before
this change would call qHash(int, size_t), and code compiled after this
change would call the catch-all qHash<Enum>(Enum, size_t); as discussed
before, the two don't yield the same results, so mixing old code and new
code will break.
In order to restore the old behavior, add a qHash overload for
enumeration types that forwards the implementation to the integer
overloads (using qToUnderlying¹).
(Here I'm considering the "old", correct behavior the one that one gets
by simply including QHash/QSet, declaring an enumeration and calling
qHash on it. In other words, without having Evil around before including
QHash.)
This avoids an ABI break for most enumeration types, for which one
does not explicitly define a qHash overload. It however *introduces*
an ABI break for enumeration types for which there is a single-argument
qHash(E) overload. This is because
- before this change, the catch-all template was called, and that
in turn called qHash(E) and XOR'ed the result with the seed;
- after this change, the newly introduced qHash overload for
enumerations gets called. It's very likely that it would not give
the same result as before.
I don't have a solution for this, so we'll have to accept the ABI
break.
Note that if one defines a two-arguments overload for an enum type,
then nothing changes there (the overload is still the best match).
3) Make plans to kill the catch-all template, for Qt 7.0 at the latest.
We've asked users to provide a two-args qHash overload for a very long
time, it's time to stop working around that.
4) Make plans to switch from overloading qHash to specializing std::hash
(or equivalent). Specializations don't overload, and we'd get rid of
all these troubles with implicit conversions.
--
¹ To nitpick, qToUnderlying may select a *different* overload than
the one selected by an implicit conversion.
That's because an unscoped enumeration without a fixed underlying type
is allowed to have an underlying type U, and implicitly convert to V,
with U and V being two different types (!).
U is "an integral type that can represent all the enumerator values"
([dcl.enum/7]). V is selected in a specific list in a specific order
([conv.prom]/3). This means that in theory a compiler can take enum E {
E1, E2 }, give it `unsigned long long` as underlying type, and still
allow for a conversion to `int`.
As far as I know, no compiler we use does something as crazy as that,
but if it's a concern, it needs to be fixed.
[ChangeLog][Deprecation Notice] Support for overloads of qHash with only
one argument is going to be removed in Qt 7. Users are encouraged to
upgrade to the two-arguments overload. Please refer to the QHash
documentation for more information.
[ChangeLog][Potentially Binary-Incompatible Changes] If an enumeration
type for which a single-argument qHash overload has been declared is
being used as a key type in QHash, QMultiHash or QSet, then objects of
these types are no longer binary compatible with code compiled against
an earlier version of Qt. It is very unlikely that such qHash overloads
exist, because enumeration types work out of the box as keys Qt
unordered associative containers; users do not need to define qHash
overloads for their custom enumerations. Note that there is no binary
incompatibity if a *two* arguments qHash overload has been declared
instead.
Fixes: QTBUG-108032
Fixes: QTBUG-107033
Pick-to: 6.2 6.4
Change-Id: I2ebffb2820c553e5fdc3a341019433793a58e3ab
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Some of the entries in QLocale's single_character_data[] table are
not, in fact, single characters; some RTL languages include
bidi-markers in some of the fields, some locales use some denotation
of "times ten to the power" as the exponent separator. There may be
further complications, but let's just get some tests in that verify we
are correctly serializing numbers in these locales. Include some
parsing tests to show that we are indeed failing them.
Task-number: QTBUG-107801
Change-Id: Iab9bfcea5fdcfcb991451920c9531e0e67d02913
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
%.f should be handled like %.0f. You probably don't want it for strings,
though.
Fixes: QTBUG-107991
Pick-to: 6.2 6.4
Change-Id: I07ec23f3cb174fb197c3fffd1721a941fbcf15e1
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
I'm not entirely sure whether this is a toolchain bug or if this is
intended. This commit ODR-uses all the static inline variables in
QOperatingSystemVersion so they are added to the list of exported
symbols in QtCore.
On Windows:
$ objdump -p bin/Qt6Core.dll | grep Windows11E
[2534] _ZN23QOperatingSystemVersion9Windows11E
On Linux:
$ eu-readelf --dyn-syms lib/libQt6Core.so | grep Windows11E
1985: 0000000000575430 16 OBJECT GNU_UNIQUE PROTECTED 18 _ZN23QOperatingSystemVersion9Windows11E@@Qt_6
Pick-to: 6.4
Change-Id: Ia317fd249bcd80dbd02c198803a3a61178c0c219
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It seems the value name correction is not needed at all,
and we must not do such correction.
Amends commit 738e05a55a
Task-number: QTBUG-107794
Change-Id: I903a762aafab4b55275beb8438e6769285821567
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Removes a warning in the build.
Pick-to: 6.4
Change-Id: I07ec23f3cb174fb197c3fffd17215c40b40333cb
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Amends edd983071e.
Remove redundant calls to AAssetDir_getNextFileName() in
AndroidAbstractFileEngine::setFileName(). It's enough to check
if AAssetManager_open() returns null and AAssetManager_openDir() is
valid for the provided asset file name.
As part of this fix, add some unit tests to cover/ensure assets
listing/iterating works as expected.
Fixes: QTBUG-107627
Pick-to: 6.4 6.2 5.15
Change-Id: I37ae9cb64fbbc60699bb748895f77fd6a34fae1f
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
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>
I wrongly assumed we can't query a value with an empty name ""
during the previous refactor commit, however, in Windows registry,
an empty name for a value means the default value of a key, we can
read and write it through the "Default" name.
Remove the wrong assert to fix the crash when we are trying to query
a default value of a key.
Add a new test case to test this kind of scenarios.
Amends commit 40523b68c1
Fixes: QTBUG-107794
Change-Id: Idacbcb86df4435a8c1ca1c19121599390ae8f3d3
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
The libraryMap only stored the file path, so we couldn't load two
versions of the same library as we'd find the other version already
loaded. Change the map to index by file name and version (using a NUL as
separator, since that can't appear in file names).
[ChangeLog][QtCore][QLibrary] Fixed a bug that caused QLibrary to be
unable to load two different versions of a library of a given name at the
same time. Note that this is often inadviseable and loading the second
library may cause a crash.
Pick-to: 6.4
Change-Id: I12a088d1ae424825abd3fffd171ce3bb0590978d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Regression introduced by commit 8d4eb292b2
in 6.0, when QTaggedPointer was introduced. We set the tag even when the
loading failed and failed to reset it because d = {} retains the tag.
Pick-to: 6.2 6.4
Fixes: QTBUG-103387
Change-Id: Ie4bb662dcb274440ab8bfffd170a07aa9c9ecfca
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
QLibrary intentionally does not unload on destruction, so failing tests
may leave libraries already loaded and cause further tests to fail
because of that. So add a cleanup() method to unload everything we may
have loaded.
Note that QLibrary::unload() sets its state to NotLoaded after one
successful call, so we must recreate the object in case it had been
load()ed multiple times.
Pick-to: 6.2 6.4
Change-Id: I12a088d1ae424825abd3fffd171d133c678f910a
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The "qhash" test relied on the fact that those four elements would
produce a different order with a zero and a non-zero seed. But since
commit b057e32dc4 removed the setting of a
deterministic non-zero seed, this test had a 1 in 4! chance of failing.
Since 4! = 24, 128 retries should be more than enough to ensure we do
find at least hash seed that provokes a different order.
Fixes: QTBUG-107725
Change-Id: I3c79b7e08fa346988dfefffd171ee61b79ca5489
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Various places were knowingly provoking warnings without telling QTest
to check for and suppress those warnings. Some others did check for
this warning, so let's consistently suppress the noise.
Change-Id: I71b9829680c7a513f4d8fbb3c57442875a6c2dc4
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
For some reason the QTest::ignoreMessage() was conditioned on the type
being tested being Array; however, the warning is in fact produced for
all types. So anticipate it for all and make the test log less noisy.
Change-Id: I78681624252ff8a71f080204f8b031609ddac468
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There were two copies of the 0x1D157 row and we can't remember why.
So change one of them to the Chakma digit 3 (a spiral) and annote all
three test-cses with what meaning Unicode assigns to them.
Change-Id: I95837588bd5944f7f2c39c8438d9076e844e4dd0
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
