Flushing the queued paint events will bump numRepaints, and the whole
point of calling reset() is to prepare a consistent state before the
next test, so we need to call it after flushing the events.
Pick-to: 6.2 6.4
Change-Id: Iaefc9854caafe82c65c9587e18fd081439e8dda6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The qfiledialog test was failing on completer_data test. The fix
available for Android 11 also works in Android 7, so removed the if
clause.
Task-number: QTBUG-105377
Change-Id: I76a4c1073a754c9b299cfe731f42b80da1a6f8e2
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
It may take some time before the shown window is available through the
accessible hierarchy, so do an asynchronous test for that to happen.
Pick-to: 6.4
Change-Id: I3f312ae636505b805899973678b1bf10a65f96b3
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
There's no need to split it, we can use the -x compiler flag to build
the .cpp file as Objective-C++, or, as done here, just rename the file.
This allows us to use QVERIFY and friends, giving more precise failure reporting.
Pick-to: 6.4
Change-Id: I6fb1c4454335082c8a39010c5b75c59e6ec6561b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
When a compound widget is created not directly before its children,
then another widget will be in the focus chain between the compound and
the compound's first child. If one of those children is then made the
focus proxy of the compound, then the widget in between becomes
unreachable by tabbing.
To fix this, detect that we set the focus proxy to be a descendent of
the compound widget, and then move the compound widget directly in front
of its first child in the focus chain. This way we can't have any gaps
in the focus chain.
Augment the test case with a corresponding scenario. As a drive-by, move
the debug helper up in the code so that it can be easier used, and set
object names on relevant widgets.
Pick-to: 6.4 6.2 5.15
Fixes: QTBUG-89156
Change-Id: I17057719a90f59629087afbd1d2ca58c1aa1d8f6
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@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 reverts commit 79a11470f3, which
resulted in QTBUG-105735. The new behavior is worse and affects multiple
screen readers, while the old issue is isolated to Windows Narrator and
could be considered a narrator bug.
Task-number: QTBUG-105735
Pick-to: 6.2 6.4
Change-Id: Ic8be1dbd592a3fdf2c3219ec4c5524bc2c7f0f6a
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
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>
When 'this' is IPv6 and 'other' is Any then there is no point in testing
'other's IPv6 address.
Added extra tests against QHostAddress::Any*.
Pick-to: 6.4 6.2 5.15
Fixes: QTBUG-108103
Change-Id: I09f32b1b147b1ec8380546c91cd89684a6bebe2e
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>
If we use winrt's factories we have to make sure to to clear the factory
cache when one of our dlls is unloaded or we will run into dangling
factory entries which might result in crashes. So we have to make sure
that winrt::clear_factory_cache is called on every dll unload.
In order not to increase compile times and dependencies too much
qfactorycacheregistration_p.h needs to be included in Qt code whenever
we use winrt's factory cache. A rule of thumb being: Include
qfactorycacheregistration_p.h whenever including winrt/base.h.
Other Qt modules which use winrt's factories need to be updated too.
Fixes: QTBUG-103611
Pick-to: 6.2 6.4
Change-Id: I7ab24e4b18bffaca653c5b7f56a66ce99212e339
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
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>
This amends 23780891a5 which moved the.txt
test to tets/auto/corelib/platform/android and kept the old location
mistakenly.
Pick-to: 6.4 6.2
Change-Id: If58422f9a94cfe4d6a941cc5453d8f0506057dcb
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Removes a warning in the build.
Pick-to: 6.4
Change-Id: I07ec23f3cb174fb197c3fffd17215c40b40333cb
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The `rcc_PREFIX` will be set to `/` if it is not passed to the
function and it is not defined in `QT_RESOURCE_PREFIX`.
I also removed an unnecessary check of the `rcc_PREFIX`.
[ChangeLog][QtCore][CMake] The `PREFIX` parameter of the
`qt_add_resources` is now optional. If not passed, and
`QT_RESOURCE_PREFIX` is not defined, `/` will be used as the path
prefix.
Fixes: QTBUG-104938
Change-Id: I6524ab5dc54f035272e4c2e3154eb67591efb650
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This introduces a new helper function accessibleIdForAccessible
(inspired by Windows' automationIdForAccessible) to synthesize an id out
of the objectNames of the accessible parent chain. The id is then
exposed via the GetAccessibleId D-Bus function for consumption in a11y
tools.
Change-Id: If72b86c5864c43f4ca842aa11423dd8aea0dde4a
Reviewed-by: Aleix Pol Gonzalez <aleixpol@kde.org>
MySQL has a different default setting for case sensitive table names on
linux and windows which makes the test fail on linux but work on
windows when using the database with the default settings. Read out the
respecitive setting so the test will pass every time.
Change-Id: I8651858d47652022ddc4b6386a6153cf70c6fed6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The QHoverEvent ctor takes two points: pos and globalPos; pos is then
passed as both the scene and global pos to the QSinglePointEvent ctor,
which calls QMutableEventPoint::setScenePosition() on the persistent
QEventPoint instance and then detaches befeore setting ephemeral state.
Therefore, we must construct QHoverEvent with scene position first, not
local position, so that the right value is persisted; it's better to set
local position after the detach(), whereas it's too late to fix the
persistent point then.
Pick-to: 6.4
Fixes: QTBUG-106918
Change-Id: I45726a9ec05bba2fe0cde6f5fb87c269105caca6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
-1 is the default value for QSurfaceFormat::alphaBufferSize. Changing it
to 0 may result an unexpected pixel format change by ARB OpenGL
extension.
Pick-to: 6.4
Fixes: QTBUG-107629
Change-Id: Ia6a1b90fba6c43b6872b406f4fd946d937135cf8
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
There is no reason to use different style of quotes when printing
messages.
Change-Id: I7d513ec04c803702974054569d28f26947942fbf
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
QWindow::requestActivate() is not supported.
This function crashed very often in ci/coin when system is busy.
Task-number: QTBUG-107153
Pick-to: 6.4 6.2
Change-Id: I82523080db40bddce9c9dc000433117d8ef74847
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
QWindow::requestActivate() is not supported.
This function failed in test vm in coin manually very often.
Task-number: QTBUG-107153
Pick-to: 6.4 6.2
Change-Id: I013651b0e5e7618c29742effd85a091ca95a7414
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
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>
According to the grafana dashboard it has not failed in the
past week.
Reverts ad736e9150
Pick-to: 6.4 6.2
Change-Id: I3eac3c7fd667cfe2cf951b2808dddbfed8eae087
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@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>
It makes it impossible to rerun it, bad for both CI and local test runs.
As a drive-by name the database file sqlite.db instead of foo.db
Pick-to: 6.2 6.4
Fixes: QTBUG-100245
Change-Id: I2e4ee01189ccbad2a6add5db7771d35fd7248da8
Reviewed-by: Dimitrios Apostolou <jimis@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Shaw <andy.shaw@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>
Two test-cases had the same name; distinguish them by the part of
their data in which they differ - one closes, the other doesn't.
Change-Id: I37051baf194bf8df742688739ad01e3335e64dc7
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Two rows shared the same name. They claimed the value used was out of
range, but actually that was only true for one of them. The other was
in range, but the test reduced the number of digits allowed after the
decimal point, thereby making it invalid, so rename that one to
reflect this.
Change-Id: I0936ea25ec799c0069cd148b9f9bae5d35906093
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Include the spacings used, to avoid a naming collision.
Change-Id: Iaf78f7142f6780dcf4c7a0b973db9f625af06767
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Avoid duplication by distinguishing similar test-cases.
Change-Id: I1a100d6c9729f0ea356f177535d15c3d36e2da9e
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The test used to trigger a lot of QWARN messages; these are clearly
intended, so tell QTest to expect them, so that we get an error here
if those warnings ever don't show up.
Incidentally tidy up a comment and convert a != verify to a
QCOMPARE_NE(), since it's now available to do that job.
Change-Id: I83e225c37abe8446dac06ebe4e75258cb87b71b0
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
In the process, clean up the building of the data tags: use a
range-for loop, albeit we do need an index to show in tags; show it
and the angle in the tags using addRow()'s easier formatting. Change
the low angle tests to show the sign of the angle (which is how they
differ)rather than just labeling them 1 and 2.
Change-Id: Ib5aaa3e22d771c530c9343ba368b0fdfceb264ce
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Jason McDonald <macadder1@gmail.com>
The last three duplicated earlier ones; and their names didn't take
into account the circle that had been added to the path since those
tests. So revise their names to reflect that.
Change-Id: I32d74f21947b4ba0c04eee53daf8efde6b4a6409
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Two rows shared a data tag. Prefixed one of them with the color of the
half-transparent image it involves (the other's is fully transparent).
Change-Id: I1bd174008ed29bcf2f460e683fdf6d1f12ba19d0
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The same data tags were used with two distinct filenames in their
data. Include the basename of each filename in the data tag, to avoid
duplication.
Change-Id: I216fecbd413fab409227ad6f93f8ac3fcc74b059
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
The "a" and "A" rows appeared under Valid, then again under Only Keys.
The two copies were identical, in each case, so drop the latter.
Change-Id: Ib3d84710e772171bb4a5e0aefd20022810fb41cd
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
tst_QDBusType::isValidFixedType_data() called addFixedTypes() and then
addBasicTypes(); but the latter calls addFixedTypes(), too; so those
rows got duplicated. Only add the fixed types once.
Change-Id: If0d6f44ec7defb12117dad251878850ca75beb48
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The row 27 that was positioned before row 01, as if it were meant to
be numbered row 00, was identical to the row 27 that appeared after
row 26. Since row 26 was the other case dealing with the null
QRectF(), I kept the one after it instead of renumbering row 00 and
deleting row 27.
Change-Id: I3585839184233f1f1629280ac9e5b25110c155c0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use key(i) rather than valueToKey(value) as the Sha3_* alias Kekkak_*
or RealSha3_*. This way, we still test all members of the enum,
without duplicating row keys (albeit the aliases duplicate values).
Change-Id: I6acba5ffdf5b68294031d609a76b37ca8fad9d94
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Both countBits() and datastream() had two copies of an all-zeros test
with 35 zeros. Removed the second, in each case.
Change-Id: I5dec4765236ae870c30828dae0f04b8902a100f0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
/Zc:lambda seems buggy. Although in my experiments it works well
for 99% Qt repos, it seems some tests will trigger the bug and it
also blocks some new commits. So disable it for now, it's not stable
enough.
Now that this check is disabled, the workaround for tst_qstringapisymmetry
is also not needed anymore, so remove the workaround as well.
Partially reverts commit 8cb832090a
Change-Id: Icf0ecbbaa6262522470e5f5dea05705985ab18f1
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
setFocus() was called on a double spinbox without calling show()
first. That causes flakiness on XCB when checking focus afterwards.
The test can still fail, when focus is acquired by e.g. a system
popup.
This patch adds a show() call before setFocus() to stabilize normal
behavior. In case the double spin box is shown, but cannot acquire
focus, the test is skipped.
Fixes: QTBUG-70088
Change-Id: If02e88800a31b09a1da63dcc074eb8bb1b0df391
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
The zlib convenience API we've been using so far has two problems:
- On Windows-64, where sizeof(long) == 4, the use of ulong for sizes
meant that we could not compress data compressable on other 64-bit
platforms (Unix). While zstream also uses ulong, being a stream API,
it allows feeding data in chunks. The total_in and total_out members
are only required for gzip compression and are otherwise just
informational. They're unsigned, so their overflow does not cause
UB. In summary, using zstream + deflate() allows us to compress more
than 4GiB of data even on Windows-64.
- On all platforms, we always allocated the output buffer in such a
way as to accommodate the pathological case of random, incompressible
data, so the output buffer was larger than the input. Using zstream
+ deflate(), we can start with a smaller buffer, then let zlib pick
up where it left off when it ran out of output buffer space, saving
memory in the common case that compression meaningfully reduces the
size. To avoid the first few rounds of reallocations, we continue to
use zlib's compressBound() for input less than 256KiB.
This completely fixes the compression side of QTBUG-106542 and
QTBUG-104972.
Pick-to: 6.4 6.3 6.2
Fixes: QTBUG-104972
Fixes: QTBUG-106542
Change-Id: Ia7e6c38403906b35462480fd611b482f05a5c59c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Add at least a few, so size() isn't completely untested.
Pick-to: 6.4 6.2 5.15
Change-Id: I500d28f7efb30ab578808d8fefb6ea57949edc2e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
A violation of coding style (requiring braces on multi-line bodies
of conditionals) was accompanied by a mis-indented else block.
Fix a long line while I'm about it.
Change-Id: Ibe9cf15eadbe9ef58138d7876e5e2c5a14a92fd4
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Pull out the arbitrary factor of three as a named constant and
document its arbitrariness once.
Pull out the mask and bit used in each function's loop to the outer
layer of the loop, since they don't depend on the inner loop variable
(or the random value generated in that loop).
Use QTest::addRow() instead of constructing a string to pass to
newRow().
Change-Id: Ifacbcb390e00828fd47f51b0c73d0ad5f6bc8bdb
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The tests for indexOf() and lastIndexOf() had duplicate data row tags,
due to only using the needle and haystack, although some tests
differed only in start position. Include start position where needed.
Change-Id: I197d415265ab1a805f2d36fb88aec92ea8646f7a
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Enclosing one string in each substring of another does not need to
repeat the empty substring of the latter. Extracting the empty
substring from different positions doesn't get different results.
In the process, tidy up the code a bit.
Change-Id: Ic66febbdadeaac0c466f4f1174d831a991d31e20
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
There were two copies of the same line in mid_data(), leading to
duplicated data row tags.
Change-Id: Ia21e855ff781b13fe18c932cff48cb0aabd12750
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The zlib convenience API we've been using so far has two problems:
- On Windows-64, where sizeof(long) == 4, the use of ulong for sizes
meant that we could not uncompress data compressed on other 64-bit
platforms (Unix). While zstream also uses ulong, being a stream API,
it allows feeding data in chunks. The total_in and total_out members
are only required for gzip compression and are otherwise just
informational. They're unsigned, so their overflow does not cause
UB. In summary, using zstream + inflate() allows us to decompress
more than 4GiB of data even on Windows-64.
- On all platforms, if the size hint in the header was too short, we'd
double the output buffer size and try again, from scratch. Using
zstream + inflate(), we still need to reallocate, but we can then
let zlib pick up where it left off when it ran out of output buffer
space. In all but the most pathological cases, copying the
already-decoded data instead of re-decoding it again should be
faster, esp. if QArrayData uses realloc() instead of malloc() +
free() to grow the buffer.
We also now directly allocate at least as much output buffer as we
have input, to cut the first few rounds of reallocations when the
expectedSize was created, as qCompress still does, using modulo
arithmetic mod 4GiB instead of saturation arithmethic.
Factor the growing of the output buffer into a wrapper function,
flate(), which can be reused when porting qCompress().
This completely fixes the uncompression side of QTBUG-106542 and
QTBUG-104972.
Pick-to: 6.4 6.3 6.2
Task-number: QTBUG-104972
Task-number: QTBUG-106542
Change-Id: I97f55ea322c24db1ac48b31c16855bc91708e7e2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The timestamp will no longer be incremented by 500ms after a mouse
release if the delay has been explicitly specified.
The default delay is 1 ms since f5010c49a3
but the running timestamp was unconditionally post-incremented by 500ms
after every mouse release, to prevent double-clicks, which were always
deemed as unintended (because we have a mouseDClick function for that).
Now, we do that 500ms increment only if the user has not provided a
delay value in the function argument at all. We have often found it
useful in our own tests to generate double-clicks "the hard way", by
sending indivdual events, so as to be able to check state in some target
object at each step, as shown in the new snippet.
[ChangeLog][QtTest] QTest::mouseRelease() and mouseClick() can now be
used to test double-clicks, by specifying a realistic timestamp delay.
Fixes: QTBUG-102441
Change-Id: I8e8d242061f79efb4c6e02638645e03661a9cd92
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Fix two tests which got broken due to the latest changes without
notifying because those tests are not run automatically.
Change-Id: Ibe9d9601f0a2ad4ce8f06ca21e7503e77fa55781
Reviewed-by: Fredrik Ålund <fredrik.alund@mimer.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This is a combination of Q_UNREACHABLE() with a return statement.
ATM, the return statement is unconditionally included. If we notice
that some compilers warn about return after __builtin_unreachable(),
then we can map Q_UNREACHABLE_RETURN(...) to Q_UNREACHABLE() without
having to touch all the code that uses explicit Q_UNREACHABLE() +
return.
The fact that Boost has BOOST_UNREACHABLE_RETURN() indicates that
there are compilers that complain about a lack of return after
Q_UNREACHABLE (we know that MSVC, ICC, and GHS are among them), as
well as compilers that complained about a return being present
(Coverity). Take this opportunity to properly adapt to Coverity, by
leaving out the return statement on this compiler.
Apply the macro around the code base, using a clang-tidy transformer
rule:
const std::string unr = "unr", val = "val", ret = "ret";
auto makeUnreachableReturn = cat("Q_UNREACHABLE_RETURN(",
ifBound(val, cat(node(val)), cat("")),
")");
auto ignoringSwitchCases = [](auto stmt) {
return anyOf(stmt, switchCase(subStmt(stmt)));
};
makeRule(
stmt(ignoringSwitchCases(stmt(isExpandedFromMacro("Q_UNREACHABLE")).bind(unr)),
nextStmt(returnStmt(optionally(hasReturnValue(expr().bind(val)))).bind(ret))),
{changeTo(node(unr), cat(makeUnreachableReturn,
";")), // TODO: why is the ; lost w/o this?
changeTo(node(ret), cat(""))},
cat("use ", makeUnreachableReturn))
);
where nextStmt() is copied from some upstream clang-tidy check's
private implementation and subStmt() is a private matcher that gives
access to SwitchCase's SubStmt.
A.k.a. qt-use-unreachable-return.
There were some false positives, suppressed them with NOLINTNEXTLINE.
They're not really false positiives, it's just that Clang sees the
world in one way and if conditonal compilation (#if) differs for other
compilers, Clang doesn't know better. This is an artifact of matching
two consecutive statements.
I haven't figured out how to remove the empty line left by the
deletion of the return statement, if it, indeed, was on a separate
line, so post-processed the patch to remove all the lines matching
^\+ *$ from the diff:
git commit -am meep
git reset --hard HEAD^
git diff HEAD..HEAD@{1} | sed '/^\+ *$/d' | recountdiff - | patch -p1
[ChangeLog][QtCore][QtAssert] Added Q_UNREACHABLE_RETURN() macro.
Change-Id: I9782939f16091c964f25b7826e1c0dbd13a71305
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For the full list, please refer to [1].
Needed to change the qstringapisymmetry unit test:
In theory we don't need the array to be static and it did compile
without any problems so far, indeed. However, with this patch applied,
MSVC complains that the lambda function below can't access the array.
I don't understand why, because we use [&] in the lambda and it should
capture all the variables in theory, but in reality it failed to
capture this variable in the end. And making the variable static
solves this issue. Maybe it's a MSVC bug.
Already tested locally. Most Qt repos build without any issues,
only very few repos are not tested, as my local environment
can't build them.
[1] https://docs.microsoft.com/en-us/cpp/build/reference/zc-conformance?view=msvc-170
Change-Id: I658427aa171ee1ae26610d0c68640b2f50789f15
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
When deploying into some directory structure where CMAKE_INSTALL_LIBDIR
is different from Qt's lib dir, we need to set the RPATH of installed
plugins such that Qt libraries are found.
We do this using CMake's undocumented file(RPATH_SET) command and pray
that this command is safe to use across current and future CMake
versions. For CMake versions < 3.21, we use patchelf, which must be
installed on the host system.
The adjustment of rpaths can be turned on explicitly by setting
QT_DEPLOY_FORCE_ADJUST_RPATHS to ON.
The usage of patchelf can be forced by setting QT_DEPLOY_USE_PATCHELF to
ON regardless of the CMake version.
Change-Id: I62ced496b4c12bf6d46735d2af7ff35130148acb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Otherwise we don't properly test whether the deployed executable can run
without adjusting the environment.
We temporarily adjust the test_widgets_app_deployment test and set
CMAKE_INSTALL_LIBDIR to make the test pass. It would now fail on Linux
distros where CMAKE_INSTALL_LIBDIR defaults to "lib64" but Qt is built
with lib dir "lib". The next commit removes this hack.
Change-Id: I63c79ef1ee23ffaeed881337fde6e9d889ecc0fe
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Unix systems have got crash loggers in the past 15-20 years, notably
macOS and Linux (abrtd, systemd-coredumpd, etc.). By setting the core
dump limit to zero, those tools should be mostly inhibited from running
and thus not interfere with the parent process' timeouts. Even for
systems without core dump loggers, disabling the writing of a core dump
to the filesystem should also help.
Pick-to: 6.4
Change-Id: I12a088d1ae424825abd3fffd171d112d0671effe
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QWindow::requestActivate() is not supported.
We have one tst_selftests binary, and will test it with both xcb and
wayland qpa plugin. A runtime check and skip will have different
restult files, which is not implemented in testlib yet.
Task-number: QTBUG-107578
Pick-to: 6.4 6.2
Change-Id: Idc8cb24c6f42a9f0f4dc9493e3fd1a5803ba7ce0
Reviewed-by: Liang Qi <liang.qi@qt.io>
