Borrowed from tst_qtemporaryfile with some changes.
Change-Id: I596ddd0ac8dbe10edd63e481198064dcec15d3e6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Many features of today's devices and operating systems can have
significant privacy, security, and performance implications if
misused. It's therefore increasingly common for platforms to
require explicit consent from the user before accessing these
features.
The Qt permission APIs allow the application to check or request
permission for such features in a cross platform manner.
The check is always synchronous, and can be used in both
library and application code, from any thread.
The request is asynchronous, and should be initiated from
application code on the main thread. The result of the request
can be delivered to lambdas, standalone functions, or
regular member functions such as slots, with an optional
context parameter to manage the lifetime of the request.
Individual permissions are distinct types, not enum values,
and can be added and extended at a later point.
Task-number: QTBUG-90498
Done-with: Timur Pocheptsov <timur.pocheptsov@qt.io>
Done-with: Volker Hilsheimer <volker.hilsheimer@qt.io>
Done-with: Mårten Nordheim <marten.nordheim@qt.io>
Change-Id: I821380bbe56bbc0178cb43e6cabbc99fdbd1235e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
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>
With -no-feature-sql, CMake would error out because the target Qt6::Sql
didn't exist. Fix this by checking if the target exists.
Task-number: QTBUG-102480
Pick-to: 6.2 6.3 6.4
Change-Id: I411631acfd336ea699833954f86711067d160c04
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Interesting on its own just because it exercises stencil testing,
unlike any of the other existing manual tests.
In addition it serves as a base example for how outlines could be
done, it is one possible approach at least. (render with stencil
write, then render again slightly scaled up with a solid color with
testing against the stencil buffer content)
Change-Id: I0c845a9004136f229cab037f6f0aab2f772bdd76
Reviewed-by: Christian Strømme <christian.stromme@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>
We currently don't have any machinery for qmake or CMake to map
translations declared via TRANSLATIONS += or qt_add_translations
to the Info.plist CFBundleLocalizations key.
This results in macOS and iOS falling back to the development region,
CFBundleDevelopmentRegion, as the only supported localization of the
app, which is in most cases set to 'en'.
Unfortunately this doesn't work well with the behavior of iOS 11+
and macOS 10.13+ where the OS will set the locale of the app to
the best match between the app's supported localizations and the
user's preferred language.
https://developer.apple.com/library/archive/qa/qa1828/
Since we only support a single localization, the development region,
the locale always ends up as 'en_<REGION>', which after QTBUG-104930
is also reflected in the QLocale's uiLanguages(), resulting in the
QTranslator machinery always picking English translation for the app.
As long as we don't explicitly declare CFBundleLocalizations we need
to opt out of the system's behavior of finding the best match between
the app's declared localizations and the user's preferences, which we
can do via the CFBundleAllowMixedLocalizations key.
Fixes: QTBUG-63324
Pick-to: 6.4
Change-Id: If7586d342148cbbb1d2a152cef039aad4448b13c
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
QTreeView draws the different sub-rects of an item's background over
multiple calls to drawPrimitive(PE_PanelItemViewRow). The item row is
not separately stylable, but the item might have a styled background
property. To get a consistent background, we must use the item's
background rule when filling the item's row background.
To fix that, delegate the filling of the branch background to
drawPrimitive(PE_PanelItemViewRow), and implement PE_PanelItemViewRow
handling to render the rule for the ViewItem pseudo element if there is
a background rule defined for it.
Add a baseline test stylesheet for this scenario. Note that the selection
in an item view is better styled via the selection-background-color
qss property.
Task-number: QTBUG-73251
Task-number: QTBUG-106227
Pick-to: 6.4 6.2
Change-Id: I5d0c170f78009fe5015dd749975e6df27485b3b8
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
The fix for QTBUG-73251 in f4976f86cd
resulted in QTBUG-106227. Add baseline test coverage for the respective
configuration to make sure we don't regress.
Refactor mapping of index to configuration to make accessing of subitems
more robust.
Task-number: QTBUG-73251
Pick-to: 6.4 6.2
Change-Id: I530ecd67fa5663f219884f641bc5e25c7ac5fe73
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
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>
After f4976f86cd, alternate rows are no
longer painted all the way, as the code is never called for styles that
don't include the tree item decoration in the selection, such as the
Windows styles.
Add a baseline test to record the appearance of such trees.
Task-number: QTBUG-106227
Pick-to: 6.4 6.2
Change-Id: If21076393fdf65205cab91299f8e557dbe9c4ea9
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
We have NTDDI_WIN10_NI (0x0A00000C) in the Win11 SDK (10.0.22621)
so bump the value in Qt (currently 0x0A00000B) to it.
And when searching for _WIN32_WINNT/WINVER/NTDDI_VERSION throughout
the whole qtbase codebase, I found some duplicated code, mostly
leftovers from the legacy time. Replace them with our own windows
header can achieve the same effect: we have defined all the necessary
macros to unblock the latest features. And place the header at the
top most place to include the macros as early as possible.
Change-Id: I37d9ac40ca9748208c7b2e89f374eda362dbefd6
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
This is consistent with what $(DEVELOPMENT_LANGUAGE) reports, as well as
the Apple Locales Programming Guide which states that "Locale names such
as “English”, “French”, and “Japanese” are deprecated in OS X and are
supported solely for backward compatibility."
Pick-to: 6.4
Change-Id: I99779d678ef9d4ea90249572f2f977e9b4df6c62
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@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>
The workaround stopped working because JSEvents is now not a global
object. Update the workaround by exporting the JSEvents object from
emscripten runtime and replacing the function that removes the
event handlers to a dummy function that does nothing temporarily, only
to revert it when the context is destroyed.
Fixes: QTBUG-107197
Pick-to: 6.4
Change-Id: Icceae884c85e04fdafcca6cf3c563094d3f6f0dc
Reviewed-by: Morten Johan Sørvig <morten.sorvig@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>
