"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>
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>
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.
Fixes: QTBUG-91448
Task-number: QTBUG-110243
Change-Id: I39c325aac91e36d53c3576a39f881949c3b21e3f
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
My FreeBSD does not have /proc mounted, so this test doesn't run almost
ever. I have no idea about OpenBSD and no one has tested Qt on AIX in
over a decade.
Change-Id: Ifbf974a4d10745b099b1fffd1777a598ee91eb5d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Emit properties with MEMBER field specified with 'readwrite'
access. Previously only READ and WRITE filed where used
for deriving the access value.
Add a property using MEMBER to the test class used by
tst_qdbuscpp2xml.
Fixes: QTBUG-115631
Change-Id: I12351985a9fafd934ccc5e0b805077a9e44b6608
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
which is flaky.
Task-number: QTBUG-115598
Pick-to: 6.6 6.5
Change-Id: Ibb0a0c6b1e225144e2ce796691c40bb7510bfd56
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
I.e. concatenating a null byte array and an empty-but-not-null byte
array should result in an empty-but-not-null byte array.
This matches the behavior of QString::append(QString) too.
Fixes: QTBUG-114238
Pick-to: 6.6
Change-Id: Id36d10ee09c08041b7dabda102df48ca6d413d8b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It relied on an implementation detail of operator+=(), that the latter
wouldn't just use assignement (e.g. if `this` is empty/null).
It also had undefined behavior, when the char array used with
fromRawData() went out of, the nested, scope, the code was pointing to a
dangling stack pointer.
Thanks to Thiago for the explanation in code review.
This ties in with further changes in this series, where append() is
changed to preserve null-ness; there is no way to preserve null-ness in
append() while keeping this unittest passing.
Change-Id: I43b9f60db9ce2d471f359f32bcc48e7b4cfceeab
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Everyone must have this by now. This test was 1193 ms of CMake time.
Since this was a PUBLIC feature, I've left it around with a constant
condition.
Change-Id: Ifbf974a4d10745b099b1fffd177754538bbff245
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
To avoid having to take high-DPI scaling into account for geometry
calculations/comparisons.
Pick-to: 6.6
Change-Id: I941b74781264455b70520df8d1e6e91592e00310
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Missing parts of local storage backend implemented:
- fallback mechanism
- removal of all child keys for groups
- variant decoding instead of string decoding
- report AccessError when organization is empty in settings' ctor
Some WASM-specific adjustments to tst_qsettings have also been
introduced.
Task-number: QTBUG-115509
Fixes: QTBUG-115037
Change-Id: I02cde965b11d98a64fc1ecb261d74838c508afd6
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Ran the scripts, added the new enum members to docs.
Updated tests:
* Two of the new languages are right-to-left,
* Canada has replaced a silly date format with a sensible one.
Fixes: QTBUG-111550
Change-Id: Ie6f1e6e94477167c9e2b5c67e6518ca0f6a7e7fb
Reviewed-by: Mate Barany <mate.barany@qt.io>
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Introduce QT_SUPPORTS_INT128 and QT_NO_INT128 marcos to handle 128-bit
types. These macros allow to undef Qt's own 128-bit types and the
related code, but keep the compiler definitions unchanged.
This is required for Qt Bluetooth, where we need to use
QT_BLUETOOTH_REMOVED_SINCE to get rid of the APIs using
QtBluetooth-specific struct quint128 which clashes with the 128-bit
types. The idea is to use QT_NO_INT128 in Qt Bluetooth's
removed_api.cpp instead of directly undef'ing __SIZEOF_INT128__,
because the latter is UB.
This commit amends befda1acca.
Pick-to: 6.6
Change-Id: Ia2c110b5744c3aaa53eda39fb44984cf5a01fac2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Commit ca54b741d6 used the internal
has_operator_equal (and commit 01d94760d8
copied that for has_operator_less_than) instead of using the recursive
expander that was being used here. That assumed that the contained type
in std::optional would always be the last final check, which is an
incorrect assumption.
Fixes: QTBUG-115646
Pick-to: 6.6 6.5
Change-Id: Ifbf974a4d10745b099b1fffd177702934bec27ff
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The blacklisted test does not crash, as its expected output indeed shows.
Pick-to: 6.5 6.6
Change-Id: I07522a7d065b5f39620975a3546bcd156024c41d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
In porting the selftest machinery to Catch2 in 24e83de8d1 we
accidentally added an unconditional early return when determining
whether to check for unexpected stderr output, resulting in not
checking error output on any platform.
The return statement has now been moved into the Q_CC_MINGW
condition, but as we now seem to have similar issues on macOS
and Linux with some of the tests outputting "Received signal 6
(SIGABRT)" as we do for QEMU, we need to add a few more explicit
early return conditions to the function.
Pick-to: 6.5 6.6
Change-Id: I7a25f000843b5f1003a5db883f08285185046b46
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Nothing prevents client code from calling QLocale::setDefault() before
we ever instantiate QLocale::system() - aside from some quirks that
mean setDefault(), currently, does instantiate QLocale::system() to
force initialization of defaultLocalePrivate - so using defaultIndex()
could set the system QLocalePrivate instance's index incorrectly.
In any case, even if the index is initially set correctly, a
subsequent change to the system locale would change the correct index;
and nothing outside QLocale::system() has access to the instance that
would then be remembering an out-of-date index.
Actually tripping over that inconsistency took some deviousness, but
was possible. The index is (currently) only used for month name
lookups and those special-case, for the Roman-derived calendars, the
system locale, to only use the index if the system locale offers no
name for a month. Meanwhile, updateSystemPrivate() uses the fallback
locale's index for its look-up of which CLDR data to copy into the
fallback QLocaleData for the system locale.
None the less, a non-Roman calendar's lookup will go via the index to
get at the CLDR data for that calendar, thereby exposing the system
locale's index to use; and, sure enough, a setDefault() could lead
that to produce wrong answers.
In QLocale::system() there's a cached QLocalePrivate, whose index we
need to ensure stays in sync with the active system locale. So pass
its &m_index to systemData(), which will now (when passed this) ensure
it's up to date. Since we always have called systemData(), to ensure
it is up to date, we can skip that update in the initialization of the
cached private and use m_index = -1 to let systemData() know when it's
in the initial call, thereby making the static cache constinit.
Amended a test to what proved the issue was present.
Change-Id: I8d7ab5830cf0bbb9265c2af2a1edc9396ddef79f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
- Pass the QList by value, no heap allocation and no plain new/delete
- A lambda means that there isn't runtime string-based lookup to find
the member method in QObjectPrivate
The code is only a couple of lines and used in a single place, so might
as well move the code from _q_reregisterTimers to the local lambda.
Modify tst_moc to account for the numer of methods in QObjectPrivate
changing. The test had hardcoded numbers.
Change-Id: I07906fc7138b8e601e4695f8d2de1b5fdd88449c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This reverts commit f647375275. There are
no signed integer overflows in atomics.
For the non-atomic side, unlike the commit being reverted, we fix the
signed integer overflow by removing the "signed" part instead of the
"overflow" part, and use unsigned integer overflows instead.
Change-Id: I53335f845a1345299031fffd176f5ba479163e44
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This commit adds some initial support for handling the 'L' suffix after
numbers. This one is especially important given that the __cplusplus
define is using it.
Other suffixes will be handled in some later commit, which should also
unify the already divergent parse behavior between DIGIT and PP_DIGIT
parsing (e.g. when it comes to byte prefixes).
Task-number: QTBUG-83160
Task-number: QTBUG-115558
Pick-to: 6.6 6.5 6.2
Change-Id: Ie61eae49c468abfaee80e7e4f7097917a254dc0e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There is no QT_CONFIG_thread.
Thanks to Alexey Edelev for spotting why I couldn't run the test.
Pick-to: 6.6 6.5
Change-Id: I11c99d9b1ff8fed67b118028b76fba8ee6db3c42
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Those tests often fail on Android 13 on RHEL 8.6 and 8.8. This patch
skips them to unblock CI while the underlying reasons are investigated
and fixed.
Task-number: QTQAINFRA-5606
Change-Id: If088d69c2160470ef50b2e74cd9b9399451c526d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Rewritten to be a bit simpler, added a few more yield/YieldProcessor
alternatives, added RISC-V support.
[ChangeLog][QtCore] Added qYieldCpu() function.
Fixes: QTBUG-103014
Change-Id: I53335f845a1345299031fffd176f59032e7400f5
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Remove stray comment at the end of tst_qexplicitlyshareddatapointer.cpp
Pick-to: 6.6
Change-Id: I31a6c38002e56e7c43e527864ba3d9324950079f
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
Remove stray comment at the end of tst_qxmlstream.cpp
Pick-to: 6.6
Change-Id: I88550e2b75194e7895d8578ca0e8350af59d4dfe
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
- rvalues, they work due to e.g. the implicit conversion to QString, so
the compiler picks the "const String &" overloads. (This may change by
adding rvalue overloads in a later commit, although that will mean
adding many more operator+() overloads to disambiguate the calls)
- QByteArray + QByteArrayView
- More P and more Q (even though in some cases P and Q are defined as
the same operator in some QStringBuilder unittest "scenarios")
Change-Id: I4e7daecdb6887fb52f45732cd32323af20b1b850
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
E.g. a group separator, a -/+ sign, or 'e' (exponent). Input ending with
one of these characters now returns Intermediate, as it can become
Acceptable if the user types more characters.
Remove a check from initialResultCheck(), as it's now covered by
QLocaleData::validateChars() checking that the last character in the
buffer is -/+, this works the same if buffer's size is 1.
Extended unittests based on the linked bug report; the other cases for
"last" are already covered by existing unittests.
Task-number: QTBUG-111371
Change-Id: I9b6979c29f07a5f57b040004cd3dbf4e27147c21
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
