Add more tests on WebAssembly platform for better tests coverage.
Change-Id: Iaaaa824ae6058a9ae5dba4c4038a7f687bfc17e0
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Take 2.
Re-land previously reverted commit, due to not handling resource names
that are not valid c++ identifiers. Now we sanitize the resource names
just like rcc does by replacing non-alphanumeric characters with
underscores.
Original commit message.
During the Qt 5 -> Qt 6 and qmake -> CMake porting time frame, it was
decided to keep resources in an object file (object library), rather
than putting them directly into a static library when doing a static
Qt build, so that the build system can take care of linking the
object file directly into the executable and thus not forcing
project developers to manually initialize resources with
the Q_INIT_RESOURCE() macro in project code.
This worked for most qmake and cmake projects, but it created
difficulties for other build systems, in the sense that these projects
would have to manually link to the resource object files, otherwise
they would get link time errors about undefined resource symbols,
assuming they kept the Q_INIT_RESOURCE() calls.
If the project code didn't contain Q_INIT_RESOURCE calls, the
situation would be even worse, the linker would not error out,
and the missing resources would only be discovered at runtime.
It's also an issue in CMake projects that try to link to the
library files directly instead of using the library target names,
which means the object files would not be automatically linked in.
Many projects try to do that because we don't yet offer a convenient
way to install libraries and reuse them in other projects (the SDK
case), so projects end up shipping only the libraries, without the
resource object files.
We can improve the situation by moving the resources back into their
associated static libraries, and only keeping a static initializer as
a separate object file / object library, which references the actual
resource initializer symbol, to ensure it does not get discarded
during linking.
This way, projects that link using targets get no behavior difference,
whereas projects linking to static libraries directly can still
successfully build as long as their sources have all the necessary
Q_INIT_RESOURCE calls.
To ensure the resource symbols do not get discarded, we use a few new
private macros. We declare the resource init symbols we want to keep as
extern symbols and then assign the symbol addresses to volatile
variables.
This prevents discarding the symbols with the compilers / linkers we
care about.
It comes at the cost of an additional static initializer per resource,
but we would get the same + a bigger performance hit if we just used
Q_INIT_RESOURCE twice (once in the object lib and once in project
code), which internally needs to traverse a linked list of all
resources to check if a resource was initialized or not.
For GHS / Integrity, we also need to use a GHS-specific pragma to keep
the symbols, which we currently use in qtdeclarative to ensure qml
plugin symbols are not discarded.
The same macros will be used in a qtdeclarative change to prevent
discarding of resources when linking to static qml plugins.
A cmake-based test case is added to verify that linking to static
libraries directly, without linking to the resource initializer
object libraries, works fine as long as the project code calls
Q_INIT_RESOURCE for the relevant resource.
This reverts commit bc88bb34ca.
Fixes: QTBUG-91448
Task-number: QTBUG-110243
Change-Id: Idce69db0cf79d3e32916750bfa61774ced977a7e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Headers must be free of Q_FOREACH uses if we want to white-list only
those .cpp files that still use Q_FOREACH in order to enable
QT_NO_FOREACH by default.
In common.h, the situation is pretty clear: the loop bodies clearly
don't modify the container being iterated over.
In MyServer, the situation is not clear at all, and this author
doesn't have the time to investigate, so take a copy and iterate over
that (eactly what Q_FOREACH does), and leave a comment.
As a drive-by, fix missing {} around multi-line loop bodies.
Task-number: QTBUG-115839
Change-Id: I06311a641c83daeee25f45522c694ac355ee86b6
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
QSqlDatabase uses a Q_APPLICATION_GLOBAL and so should not be used
without QCoreApplication instance. The test crashes if the existence
of an application instance is asserted in Q_APPLICATION_GLOBAL
code.
Pick-to: 6.6
Change-Id: Iaa3f4dff7b2722257735680dd3885aeed0ac810b
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
operator=(~) and assign(~) share similar names but, until now, have not
shared the same functionality. This patch introduces the usage of
QByteArray::assign() within the non-sharing assignment operator to
effectively boost efficiency by reusing the available capacity.
Since these assignment operators are frequently used in many places,
both within Qt and non-Qt code, this patch comes with benchmarks.
The preview of the benchmark results are compared with this patch and
before this patch. The findings indicate a slight enhancement in
performance associated with the assignment operator. Despite the results
displaying only a minor improvement, progress has been made. Therefore
use assign(QByteArrayView) as replacement.
(x86_64-little_endian-lp64 shared (dynamic) release build (O3); by
gcc 13.2.1, endeavouros ; 13th Gen Intel(R) Core(TM) i9-13900K
benchmarks executed with -perf -iterations 1000000
* The last value at the EOL represent the string size.
QByteArray &operator=(const char *ch) (current)
65 cycles/iter; 317 instructions/iter; 16.0 nsec/iter (5)
71.7 cycles/iter; 383 instructions/iter; 13.0 nsec/iter (10)
59.8 cycles/iter; 318 instructions/iter; 10.9 nsec/iter (20)
70.8 cycles/iter; 340 instructions/iter; 12.9 nsec/iter (50)
80.2 cycles/iter; 419 instructions/iter; 14.6 nsec/iter (100)
164.2 cycles/iter; 899 instructions/iter; 29.9 nsec/iter (500)
260.5 cycles/iter; 1522 instructions/iter; 45.6 nsec/iter (1'000)
QByteArray &operator=(const char *ch) (before)
66.8 cycles/iter; 317 instructions/iter; 16.9 nsec/iter (5)
76.5 cycles/iter; 383 instructions/iter; 13.9 nsec/iter (10)
63.7 cycles/iter; 318 instructions/iter; 11.6 nsec/iter (20)
71.6 cycles/iter; 344 instructions/iter; 13.0 nsec/iter (50)
77.5 cycles/iter; 419 instructions/iter; 14.1 nsec/iter (100)
143.4 cycles/iter; 893 instructions/iter; 26.1 nsec/iter (500)
270.8 cycles/iter; 1516 instructions/iter; 48.2 nsec/iter (1'000)
Task-number: QTBUG-106201
Change-Id: I0745c33f0f61f1d844a60960cc55f565320d5945
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Test sendEventsOnProcessEvents has been noticed to fail when
qgtk3 (Glib) is loaded - Should be fixed in QTBUG-87137
Moving test from blacklist to use QEXPECT_FAIL as it's more
recommended until test is fixed in the relevant configurations.
QEXPECT_FAIL is selected to use as original investigator
reported also some cases when glib is working. Therefore
this approach is giving us more insight for further
investigation is it always failing with glib or not.
It was also reported linkage to zeroTimer test QTBUG-84291,
but not sure why removing that has affected to this one.
Update to QEXPECT_FAIL documentation to tell in first place
that XPASS is not only marking it as XPASS but also failing
the test. Same is mentioned in different location but it
needs more searching or testing how it works in real test.
Task-number: QTBUG-115155
Change-Id: I7fb4ef28dba8adb7009be528f88fc758a12e9006
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Instead of copying a list, sorting it just to check it's sorted, and
making a QSet out of it just to check the size is the same as that of
the list (thereby checking there were no duplicates), simply apply
adjacent_find with greater_equal. If none of the elements is ≥ their
successor, that means all elements are < their successor, and _that_
means the range is sorted and has no duplicates. q.e.d.
Pick-to: 6.6 6.5
Change-Id: Id73c674ad4e29117370e8fc6af9fdfc690a3fba9
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
As a header, it would otherwise make all TUs that include it (with
PCH: all) incompatible with QT_NO_FOREACH.
Without deeper analysis (which economy of time forbids in this case,
given this is just a manual test that's probably run 10 times per
year), and seeing as this is in an event handler, I opted to play it
safe and iterate over a copy (which is exactly what Q_FOREACH
does). Added a comment to indicate it may not be needed.
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: I7db75321dd34888f6dd7a64cccb7462ff35935fa
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
First include the common tst_qmimedatabase.cpp (and nothing else),
then implement the differing
tst_QMimeDatabase::initTestCaseInternal().
This will allow adding #undef QT_NO_FOREACH to tst_qmimedatabase.cpp
in the next step.
Pick-to: 6.6 6.5
Change-Id: Icc1890229e9443bd35c81d4f0440ba7df5da906c
Reviewed-by: David Faure <david.faure@kdab.com>
The single Q_FOREACH use here is simple, as it's over a local variable
that just isn't marked as const due to the way it's constructed, and
the loop body clearly doesn't modify the container, so the protective
copy that Q_FOREACH performs is not needed. But std::as_const() is, to
prevent a detach() (attempt). Add that.
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: If228f649efd87388f6e312078b24a5b46ac8dc36
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: David Faure <david.faure@kdab.com>
Drag the QCOMPARE (which even dynamically allocated a QString
fromLatin1()) out of the QBENCHMARK loop. Testing performance of
QString::fromLatin1() and/or qCompare() is not pertinent to the task
at hand, which, ideally, doesn't involve any memory allocations, so
there's at least the chance that this skewed the result noticably.
Didn't run the benchmark as this was developed on an asan build.
Yes, this breaks comparability with the stone-age measurements
reported in comments there, so sue me.
As a drive-by, replace the fromLatin1() with a u_s UDL.
Pick-to: 6.6 6.5
Change-Id: I9b2a8b2e3596ec9b07c6b4ea369257b1a86e09db
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: David Faure <david.faure@kdab.com>
Various comments need to continue using the enumdata.py names, as they
associate data with particular enum members, but we can now correctly
use the en.xml versions of their names when we report them, rather
than the enum-friendly names we use in the code. Since this now means
the data may stray outside plain ASCII - it'll be UTF-8-encoded - this
implies replacing the QLatin1StringView()s of the code that formerly
read this data with QString::fromUtf8().
Fixes: QTBUG-94460
Change-Id: Id3b08875a46af58c0555c3e303b0e15a19441509
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We could already use dashes in some, rather than spaces, and now no
longer need to capitalize each word. This changes the *_name_list[]
entries for affected languages to more closely match what CLDR gives
as their names. It also amends various comments. Added tests for the
QLocale::*ToString() functions to cover the entries changed.
Task-number: QTBUG-94460
Change-Id: I0163795cb282881f15a97be00a5311c1936c3a09
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Test names and output need to be UTF-8 for the XML data formats to not
end up malformed - which would upset Coin's testrunner, when it
validates the XML as part of checking - and the few other uses of
toLatin1() were to ASCII content anyway, so can harmlessly (this being
test code, where the slight performance advantage of Latin-1 doesn't
matter) use toUtf8() as well, for the sake of uniformity.
Use of toLatin1() broke an imminent commit in which some territory,
script and language names depart from ASCII, leading to malformed
UTF-8 when they appear in test-data-row names.
Task-number: QTBUG-94460
Change-Id: Ifb826b1e417ba24fd862b93d24d0e7a38858a17f
Reviewed-by: Dimitrios Apostolou <jimis@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The following commits neglected to amend
tst_QImageReader::supportsOption() with the ImageOption enumerators
they added to QImageIOHandler:
- c0ba249a48
- 163af2cf53
- ba323b04cd
Fix first and foremost by adding the missing ImageOption::ImageFormat
to the list of PNG-supported formats (which, curiously enough, predates
the public history and therefore the above three commits), and second,
by rewriting the whole test function to enable -Wswitch, so further
additions are less likely to be forgotten.
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I102121b2c8a9067864b8ade2ebe2650be6fb6010
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Ivan Komissarov <ABBAPOH@gmail.com>
Identifiers matching _[A-Z_].* are reserved for use by the C++
implementation. Replace the __ prefix of variable names with _v_,
making them non-reserved.
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I35127d7473678e2efd93a4b21847db562c53abd2
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
In main.cpp, the loop is over a local variable which would be const
were it not for the multi-step initialization that I didn't want to
change. The loop body clearly doesn't modify the container, so port to
ranged for loop with std::as_const().
In printvolumes.cpp, the loop _does_ invoke unknown code (through the
function pointer passed as the second argument), but, as could be
expected, the two users of the function don't pass functions that know
about `volumes`:
- in the tst_QStorageInfo auto-test, an rvalue `volumes` is passed,
so we don't need to analyze the qInfoPrinter function passed there,
as it cannot possibly reference the temporary
- and in main.cpp of the manual test, we just pass printf (which is
technically UB (taking the address of a standard library function),
but I don't care right now).
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: Ibcd10a0e0b3229d8f2a1d98545d8fa6d473a0f75
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Most of these are of trivial kind (loops over const locals).
The one that isn't, in cleanupTestCase(), is, however, also simple:
it's a loop over a local, too, but it would be too much churn to
change the initialization to make the container const, and the loop
body clearly doesn't modify the container, so just go with the
std::as_const() pattern here.
Task-number: QTBUG-115839
Pick-to: 6.6 6.5
Change-Id: I188a78ea67a63be2d50a81fea431e5ea9f2783cb
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
I'd previously understood CLDR's minimumGroupingDigits to mean the
most significant group must have that many digits. It turns out to
mean only that the first grouping separator doesn't get added unless
the more significant group has this many. Once we have one separator,
more can be added that do isolate a single digit.
In the process, I discover some of the prior arithmetic is incorrect;
it is now fixed. Added some basic testing, amended some existing
tests. In the process, fixed naming of some double validator tests.
Pick-to: 6.6 6.5
Fixes: QTBUG-115740
Change-Id: Ia6ce011ba72e72428b015ca22b97d815ebf751b2
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
This source file is included in four other test projects, so it makes
more sense to port it away from Q_FOREACH than to white-list it
everywhere it's used.
The change in ModelMoveCommand::doCommand() is trivial. I only dropped
the pointless top-level const of the loop variable as a drive-by.
The change regarding `parents` in ModelChangeChildrenLayoutsCommand's
doCommand() is also trivial, I just ported to braced initialization to
get the QList to be const. We're forced by the Qt API
(layoutChanged()) to use a QList here, therefore no array.
Ibid., the change regarding `persistent` is simple. The container
cannot be marked as const without a lot of churn to its initialization
(applying IILE, basically), but other than that, it's a local
variable, and the loop body clearly doesn't modify it.
Task-number: QTBUG-115839
Pick-to: 6.6 6.5
Change-Id: I7a0e85804626a3cc612921b49e72e4b9f30b676d
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
"Never use a dynamically-sized container for statically-sized data."
Port the loop from Q_FOREACH (which can't deal with arrays) to ranged
for (which can).
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: Ib89d07fb751e3905a230ee5641e2e509e9415bed
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
There was a gap in its numbering, and the quick brown fix could do
with some competition.
Change-Id: I1283bbb6ba321ae2b65b4459327f2428a45f85cc
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This one isn't trivial, but straight-forward: the only place the
container is modified is in fill(). Like the setOpaqueChildren()
function, this is only called from top-level test functions, and, in
particular, not from event handlers (setAttribute() sends events).
That fill() doesn't clear() the container, even though the single
UpdateWidget instance is being reused across test functions, looks
wrong, but doesn't invalidate this analysis.
Task-number: QTBUG-115803
Change-Id: I284a19da2fe476278986c61810dd334fc73034b0
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The Q_FOREACH is in a header, so we need to port away from it,
otherwise it makes any TU that includes it (in PCH builds: all)
incompatible with QT_NO_FOREACH.
This is a trivial case of marking the local constructor const, but go
a step further and replace the QList with a C array ("never use a
dynamically-sized container for statically-sized data"). Both
consumers of the container (after s/foreach/for/) can deal with array.
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: I142e438dcf2d785bb34022a3fb1ff46b8eaa0edd
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
This is more readable and at the same time helps to eradicate some
more Q_FOREACH uses for an eventual global QT_NO_FOREACH for all Qt
sources (QTBUG-115796).
Task-number: QTBUG-115803
Change-Id: I9cbe76bee8a6306fab0c0bc94cd874405ca825ba
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
"Never use a dynamically-sized container for statically-sized data."
Port the loop from Q_FOREACH (which can't deal with arrays) to ranged
for (which can).
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: I40773a0397b83cce0c803967ee3fd7ae274933d3
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
"Never use a dynamically-sized container for statically-sized data."
Port the loop from Q_FOREACH (which can't deal with arrays) to ranged
for (which can).
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: Ifef42704c4f695a8fb05ea5d9b3e095af3f35171
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
"Never use a dynamically-sized container for statically-sized data."
Port the loop from Q_FOREACH (which can't deal with arrays) to ranged
for (which can).
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: Iecfc037c8bbfc0b3196ed0c65f680768a8d2353a
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
QList rather pointlessly has a startsWith() function, which means this
code compiled. But the code makes no sense: it tests the same
condition over and over again, so I'm assuming that it should be
path.startsWith() and not path_s_.startsWith().
Amends 3f56950862, but that just
imported the code from qttools. I didn't check whether the bug was
present there, already.
Pick-to: 6.6 6.5
Change-Id: I98a4bbfe0400700655a5c2137f7a976a835a8d28
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
These are all trivial: all are over (already or newly-made) const
local variables, albeit sometimes at the cost of an extra scope
(can't, yet, use C++20 ranged for loops with initializer).
In resizeMaximizedChildWindows(), decided to leave the container
construction as-is and use std::as_const instead (applying IILE to
make the container const would be too much churn).
In setViewMode(), removed a pointless clear() that prevented the
container from being marked const. There are no references to the
container following the clear(), and the container does not hold smart
pointers, so the clear() cannot have had non-trivial side-effects.
Pick-to: 6.6 6.5
Task-number: QTBUG-115803
Change-Id: I00ce9c12ab696de30229f3605c16313af7eafffc
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The single use of Q_FOREACH in this test is safe to port 1:1 to a
ranged for-loop, since we're in a constructor, and the loop body only
calls member functions of data members (incl. the base class), so we
cannot possibly modify the container passed in as a constructor
argument: any connections or event processing that could re-enter our
caller hasn't been set up, yet.
Task-number: QTBUG-115803
Change-Id: I7095aef1edddbda0d1b0c471192b18acd6fd1793
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
These are all simple: QObject::children() returns a reference-to-const
QList, so we can leave the calls in the for loop (no detach()ing).
The loop bodies also clearly don't modify the list of the QObject
children (they're just QVERIFYs).
Pick-to: 6.6 6.5
Task-number: QTBUG-115803
Change-Id: I9c5dcb2aefc433a1dead55dab669e645b6906963
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
This is iterating over data member containers that are otherwise only
touched in the constructor of the same object. Luckily, the
initialization of these containers does not require *this, so use
NSDMI and mark the containers const, proving they can never be
modified and thus the protective copy of Q_FOREACH isn't required. Now
that we got rid of Q_FOREACH, we can and do make them arrays for extra
measure ("never use dynamically-sized containers for statically-sized
data").
Unfortunately, C++ neither allows us to use "flexible array
members" nor AAA in NSDMI, so grab the nettle and supply the array
size manually (ever so slightly violating DRY, but the compiler will
complain if we get it wrong).
Task-number: QTBUG-115803
Pick-to: 6.6 6.5
Change-Id: Ibb2ce48b6dcaf2e9d3d1a625602f3865d280c7c6
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This is iterating over a data member container that's otherwise only
touched in the constructor of the same object. The only reason why
it's not a const is that the initialization from QWizard::addPage()
makes that very cumbersome. So port to a ranged for-loop and apply
std::as_const().
Task-number: QTBUG-115803
Pick-to: 6.6 6.5
Change-Id: I033e3725df95b29a8ef295c4e74d746d83234835
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This is iterating over the keys() of a member container we've just
filled in the same function. The loop body clearly doesn't modify the
container being iterated over. Port to the future-proof ranged
for-loop over asKeyValueRange(), using the _-in-SB pattern Christian
Ehrlicher showed me to indicate we're not interested in the value.
Task-number: QTBUG-115803
Pick-to: 6.6 6.5
Change-Id: I3d86a1de9ea460b7d57fa421ea76e41d2c122f43
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This is safe to port to a ranged for loop, as it's iterating over a
private member container that is not modified under iteration
(WizardPage::shown() is just returning a boolean member).
Task-number: QTBUG-115803
Pick-to: 6.6 6.5
Change-Id: I50891e4b7509bd64399a128a5ee47d7795374f8e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This function is called only from one test function. Mark the
function's argument as const in the caller, bringing this use into the
const-local category, which is implicitly safe to port 1:1 to
ranged-for.
Task-number: QTBUG-115803
Pick-to: 6.6 6.5
Change-Id: I9145c1ae2aed5ab3cafc4947dc3eaaf9a27c6a04
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Fix typo so tst_qfuture on platforms without exceptions can be build
correctly.
Change-Id: I32c12effdda13da9c8669bfddd362acc1c8a14c7
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
For the child windows we have to use showNormal() explicitly,
as the default window state logic of platforms like iOS does
not have access to the QWindow, only to its flags, and we
can not use Qt::SubWindow as a proxy for being a child window,
as that's a window flag meant to be used for MDI sub windows.
Pick-to: 6.6
Change-Id: I2b5e669f6180ffdcb75479dece38ae5e5430aef6
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Ran the script, no new IDs to add. Revised tests of Central Standard
Time: America/Ojinaga has joined Matamoros for it, in Mexico.
Pick-to: 6.6 6.5
Fixes: QTBUG-115732
Task-number: QTBUG-111550
Change-Id: I9b41d8c0156b9fbe3961dbe9a35d55493fc55501
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
These are all trivial: all are over (already or newly-made) const
local variables.
The only noteworthy point here is that, in order to mark it as const,
I had to move a container definition to the more narrow scope in which
it was actually initialized. There are no references to the container
outside the narrow scope that would require it to be defined in the
larger scope.
Pick-to: 6.6 6.5
Task-number: QTBUG-115803
Change-Id: I20890f48a48ca662679f55fa5db759419d4db8c5
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
These are all trivial: all are over (already or newly-made) const
local variables.
Pick-to: 6.6 6.5
Task-number: QTBUG-115803
Change-Id: Idd6e65065ee27c2d29ce1b49607aadb2eaf5e15d
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
