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
Change-Id: Ie61eae49c468abfaee80e7e4f7097917a254dc0e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit f0039bd517)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
There is no QT_CONFIG_thread.
Thanks to Alexey Edelev for spotting why I couldn't run the test.
Change-Id: I11c99d9b1ff8fed67b118028b76fba8ee6db3c42
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 4693c81268)
mouseMoveEvent overrides in QColorLuminancePicker and QColorPicker
have triggered value changes unconditionally. This happened under the
assumption that the widget attribute WA_Hover is not set (which is the
default behavior). In that case, mouseMoveEvents are only delivered if
a button is pressed.
If WA_Hover is set - e.g. by applying a style sheet - mouseMoveEvents
get delivered also when no button is pressed. This leads to faulty
behavior: The color and the luminance change, whenever the mouse is
moved into the respective widget. Color/luminance are changed to the
value representing the edge on which the mouse has left the area.
This patch changes both mouseMoveEvent overrides. They return early
to avoid hovering changing the colors of the luminance/color picker,
but ignore() the event in case anything behind the picker needs hover.
Since this is a purely graphical effect, an autotest was not added.
Fixes: QTBUG-115516
Change-Id: I000d113a1c81c46799cbb5197bf9acb3849e7d3b
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry picked from commit a2ec43b8eb)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We dropped support for macOS 10.3 in Qt 4.6, 14 years ago.
But the logic to only 'fake' the unloading on Q_OS_DARWIN
remains. Also, add a statement explaining the behavior
in more detail.
Change-Id: I62ec7df7c4b807f84c96619f78b3cef704c51335
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit ea0b7dafb2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Qt insight's TP is using plugin type "generic" so that insight plugins
can be deployed for every Qt application. As "generic" plugins are part
of QtGui windeployqt deploys these if a dependency to QtGui is found.
As defaulting to a deployment of insight plugins might cause confusion
among users, we make deployment of these plugins explicit if the module
is available.
Change-Id: I9d2a8595373d5a15b7afbeaf7174226563b1cb6f
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Timothée Keller <timothee.keller@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit ae7bc8803f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
A regression was introduced in
48841c34d2
when configuring qtshadertools with -prefix -debug and
no -developer-build.
qtbase would have been built as Debug, but qtshadertools as release.
This caused qsb.exe to link to a debug c++ runtime via QtCore, and a
release one via QtShaderTools libraries and thus cause heap corruption
crashes during runtime due to the mismatch.
This happened because the check in cmake/QtSetup.cmake thought Debug
was the default build type (nothing was specified on the command line)
without knowing it was explicitly set BuildInternals.
Set a variable when BuildInternals sets CMAKE_BUILD_TYPE and make
sure QtSetup does not override it then.
Augments 33af62db37
Amends 48841c34d2
Fixes: QTBUG-114958
Change-Id: I5e0a27b4d77512494c026dd911ec5757889a5a1a
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 8c912cddeb)
Before this change, we had the following behaviors.
On platforms other than Windows-MSVC:
- when no build type was specified, we defaulted to Release
- when -developer-build was specified, we defaulted to Debug
- regardless of platform, unless the option was explicitly specified,
we never defaulted to -debug-and-release.
On Windows-MSVC, we always defaulted to Debug. Which is inconsistent
with the rules above.
The difference happens because CMake always sets CMAKE_BUILD_TYPE to
Debug during the first project() call when targeting the Windows-MSVC
platform.
We interpreted that as the user setting the build type, and thus we
didn't want to override what the user specified.
After this change, if we detect that it's cmake setting the build
type, we assign a build type that follows the non-Windows-MSVC rules.
This change unifies the behavior across all platforms.
Adjusted the configure help with the new reality.
Augments 33af62db37
[ChangeLog][configure] When no explicit build type is specified,
Windows will now default to building Release like the other
platforms.
Change-Id: Id2bf269c51cf300ec09751ece2ad721869e0f90c
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 48841c34d2)
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The docs were never added (unlike the docs for erase_if).
Change-Id: I7857c5eded68791ddfc4e6ce42a60d5736f5a438
Fixes: QTBUG-115473
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 76e650045e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We do not need the Q_CC_GNU check, as the __SIZEOF_INT128__ check is
enough.
Change-Id: I12bdd02186c4f5dad0ab3f4596f4b37e5c3f7eee
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 27b06e50e0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Use QT_DEPRECATED_VERSION_X_6_6 and provide reasons for deprecation
for the enum value and for the QPropertyObserver constructor.
Change-Id: I0f9b4c6dc8bb9fd5eac692a6953c90059f3c77ef
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit aaa8c38353)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The description in terms of timeouts was confusing. Instead, say what
it actually does, in plain terms. Mention that you can do similar for
a duration.
Task-number: QTBUG-115447
Change-Id: I4618d7fa290e7959ed3cb51e5c2576b041f77091
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 669470e2be)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Remove stray comment at the end of tst_qexplicitlyshareddatapointer.cpp
Change-Id: I31a6c38002e56e7c43e527864ba3d9324950079f
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
(cherry picked from commit 93e9d21490)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Remove stray comment at the end of tst_qxmlstream.cpp
Change-Id: I88550e2b75194e7895d8578ca0e8350af59d4dfe
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
(cherry picked from commit 3bb991ca05)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The existing signal connection can cause a loop and undefined behavior
in the interaction between the line edit for a hex rgb color and the
individual rgb values.
=> Change connection to textEdited, to react only on manual editing.
Fixes: QTBUG-115189
Change-Id: Ie3062c575652b905a8ab16edb2f5f77f8d150f36
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
(cherry picked from commit 4a26ae1b27)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Amends commit 94de5f9b25 so that every
change to the default locale is reflected in an update to the default
collator used by QString::localeAwareCompare().
Although the change to the system locale does update the QLocaleData
object shared by all system locale objects, the possible change to its
collator() may imply the default collator needs an update; and the
collator backend's init() may use the language, script and territory
that's changed in setting up the revised collator, even if the QLocale
instance referenced has the same QLocaleData.
Change-Id: I957486c03c3d779fc9a2f0b889346ec13b1af868
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
(cherry picked from commit df736da245)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When parsing a string whose time-zone part matches local time's name,
use local time in preference to the QTimeZone with that name. The case
is ambiguous, and the bug was already fixed (by something else) in
dev, but this caused a failure in 6.2 through 6.5; and using local
time is more natural to QDateTime in any case. The fix incidentally
makes the the logic of the zone-resolution code more straightforward
and a closer match to how findTimeZone() found the match.
The issue was hidden from 6.6 by a change [*] to the handling of POSIX
rules, that lead to plain abbreviations such as CEST and BST - for
which the IANA DB has no entry - no longer being considered "valid"
zones, despite being technically valid POSIX zone descriptors
(effectively as aliases for UTC).
[*] commit 41c561ddde
Fixes: QTBUG-114575
Change-Id: I4369901afd26961d038e382f4c4a7beb83659ad7
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit ca6a0fd63f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Since QDateTime uses some fall-backs if qTzName() doesn't give it
something useful (as happens on MS-Win when local time is UTC),
QDateTimeParser should check the result of those fall-backs as well as
the qTzName()s when checking for local-time as zone.
Change-Id: Ic809b7e44cd0c83fb076b24c27547268345fa379
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
(cherry picked from commit c888e3922d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QSpan is Qt's version of std::span. While we usually try not to
reimplement std functionality anymore, the situation is different with
QSpan. Spans are non-owning containers, so the usual impedance
mismatch between owning STL and Qt containers doesn't apply here:
QSpan implicitly converts to std::span and vice versa, making STL and
Qt APIs using spans completely interoperable.
We add QSpan mainly for two reasons: First, we don't want to wait
until we require C++20 in Qt and can use std::span. Second, in the
view of this author, some design decisions in std::span hurt the
primary use-case of spans: type-erasure for containers. This results
in two major deviations of QSpan from std::span: First, any rvalue
container is convertible to QSpan, allowing seamless passing of owning
containers to functions taking spans:
void sspan(std::span<T>);
void qspan(QSpan<T>);
std::vector<T> v();
sspan(v()); // ERROR: rvalue owning container
auto tmp = v();
sspan(tmp); // OK, lvalue
qspan(v()); // OK
This author believes that it's more helpful to have compilers and
static checkers warn about a particular wrong usage than to make
perfectly valid use-cases impossible or needlessly verbose to code.
The second deviation from std::span is that fixed-size span
constructors are also implicit. This isn't as clear-cut, because an
explicit QSpan{arg} isn't per-se bad. However, it means you can't
transparently change from a function taking decltype(arg) to one
taking QSpan and back. Since that's exactly what we intend to do in Qt
going forward, in the interest of source-compatibility, the ctors are
all implicit.
Otherwise, the API of QSpan follows the std::span API very
closely. Like std::span, QSpan isn't equality_comparable, because it's
not clear what equality means for spans (element-wise equal, or (ptr,
size)-wise equal?). The major API additions are Qt-ish versions of std
API functions: isEmpty() on top of empty() and sliced() instead of
subspan(). The (nullary) first()/last() functions (Qt speak for
front()/back()) clash with the std::span function templates of the
same name, so are not provided.
This patch adds QSpan as private API. We intend to make it public API
in the future.
Fixes: QTBUG-108124
Change-Id: I3f660be90eb408b9e66ff9eacf5da4cba17212a6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit f82cf6333e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
It actually takes one parameter, because in this overload the connection
type can't be specified, for example:
QTimer timer;
timer.callOnTimeout([]() { qDebug() << "slot"; });
The call chain is:
QObject::connect(timer, &QTimer::timeout, functor);
connect(const typename QtPrivate::FunctionPointer<Func1>::Object *sender, Func1 signal, Func2 &&slot)
connect(sender, signal, sender, std::forward<Func2>(slot), Qt::DirectConnection);
the connection type is always DirectConnection.
Spotted by Giuseppe in code review.
Change-Id: Ia8bbd91e98a357244cbfae4e3ed63d4c73038fa2
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
(cherry picked from commit 794e0d1ac6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
They aren't used because the C++11 atomics are the only atomics we've
supported since commit 9d1fab424e (5.6).
Change-Id: I53335f845a1345299031fffd176f84ccd054b804
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit 9bcf82afb3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
... so it can use the new QMetaCallEvent() ctors taking that type.
As a consequence, the slot object ref-count is now no longer touched
on the way into the meta-call event (was: upped in QMetaCallEvent
ctor, then downed in QScopeGuard).
Manual conflict resolutions:
- QScopeGuard -> custom Holder struct
Change-Id: Id9bd157792458a3834809c23e94ca5f504f7abd1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 4015f81d31)
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This makes it clear who is responsible for obtaining additional strong
reference to the slot objects, because these functions no longer do.
Change-Id: I39187e3c441d8f82d50d907731f1cbdfb2a95b9d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 00dbd3cd26)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This is for consistency with QObject::connectImpl() and
QObjectPrivate::connectImpl(), if nothing else.
See the commit message of the QObject::connectImpl() porting patch for
why we leave the function signature unchanged (key-word:
tail-callability).
Change-Id: I515d3be4a5126f9f4738dd7bde5174377faf2343
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit ff75ace02d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
... removing the custom scope-guard which was .dismiss()ed too early
(the allocation of 'c' could theoretically fail, and the old code
would leak the slot object in that case; nothing we're generally
guarding against in Qt, but it's a nice drive-by gain, probably shuts
up static checkers, and makes readers wonder less about the lifetime
of the slot object).
As mentioned in the patch porting QObject::connectImpl(), leave the
unique_ptr out of the function's signature, see there for rationale
(key-word: tail-callability).
Change-Id: Ib90371b9768a72fd62d080b71eef2c82f851db81
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 18857db2dd)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This gets rid of the smell that one destroyIfLastRef() call guarded
against nullptr while the other one did not.
Don't change the function signatures, as passing by unique_ptr, while
making the transfer of ownership clear, makes it impossible to call
the function as a tail-call: Non-trivially-copyable arguments live in
the caller's stack frame and the caller has no idea whether the object
was moved from in the callee or not, so it needs to run the dtor,
which prevents this from being tail-callable.
Passing .release(), OTOH, makes it obvious that the unique_ptr is
nullptr afterwards, so leaves the door open for tail-calling.
However, the QObjectPrivate::connectImpl() wasn't, and continues to
not be, a tail-call. Investigating why, while intriguing, is for
another patch (and much more important for the template wrappers of
these functions than then one out-of-line function we're dealing with
here).
Change-Id: Ib951ed2a2b622d70cb12ddbf01c83ec56b1ce70d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 9338207018)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When, like in tst_QFactoryLoader::extraSearchPath(), where asan caught
it, or, presumably, on re-creation of a QGuiApplication with a
different QT_QPA_PLATFORM_PLUGIN_PATH, setExtraSearchPath() is called
with a different path than before, then it would leak QLibaryPrivate
objects in the call to libraryList.clear().
Fix by adding QLibraryPrivate::Deleter and holding the objects in
unique_ptr<QLibraryPrivate, Deleter> instead of as raw pointers. This
statically guarantees we're not leaking these objects anywhere else in
QFactoryLoader.
Change the name of the container from libraryList to libraries to catch
any unported users, incl. in older branches.
Since libraryList is now a std::vector (QList cannot hold move-only
types), statically assert that it was never attempted to be copied or
moved, even in older branches, with Q_DISABLE_COPY_MOVE().
Amends ddba24535f.
Not picking to 6.4 and 6.3, as they are closed at this point.
Fixes: QTBUG-115286
Change-Id: I6d1272622b12c505975cc72f9aba0d126d2817e2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit e60aed5ed0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
By the time QObject::destroyed() is emitted from ~QObject(), sender no
longer is-a SenderObject, only a QObject, so calling a SenderObject
member function on it is UB.
Says UBSan:
tst_qfuture.cpp:3854:84: runtime error: member call on address 0x60200000e550 which does not point to an object of type 'SenderObject'
0x60200000e550: note: object is of type 'QObject'
00 00 00 00 e8 3f 96 c9 51 7f 00 00 80 3e 00 00 c0 60 00 00 02 11 00 00 08 00 00 00 16 00 00 72
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QObject'
Fix by removing the QObject::connect().
This, of course, breaks the test's WHEN, but I don't see how to keep
that WHEN without the UB. At least the THEN part is not invalidated,
and there doesn't appear to be another test that tests that destroying
objects before signal emission results in a cancelled future.
Amends 612f6999c8.
Change-Id: I38ca4611c071e8fd200393b600210e36d4030bc6
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 4b0261fed0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
It doesn't make sense to disturb users with the policy warning if they
don't specify Android paths. Suppress the policy check if Android
paths are not set for the target.
Fixes: QTBUG-115119
Change-Id: Ice9d0459c01feb505857133bb942b1b6e775e55a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 575b8a7fa2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
These pages are designed as tutorials, so
they can be \page instead of \example.
Also, reorganized the tutorials, moving them out
of the testlib manual, into several qdoc files.
Task-number: QTBUG-115248
Change-Id: I2cbd66ecc1082ecc9d3d1742b621ee009daf1031
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
(cherry picked from commit 28defcfb78)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Exclude TUs that cause problems in a build where all of QtWidgets's .cpp
files end up in a single unity_0_cxx.cxx. This should ensure that the
build will forthwith not fail because someone added a new .cpp file in
the "wrong" position.
Of course, this is just a snapshot, with my configuration: GCC 13,
Ubuntu 20.04, -developer-build, C++23, -sctp.
Task-number: QTBUG-115352
Change-Id: I6a445701e2ac41d67a3ec69715b7bf6ed5ec65f7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit b91891a76b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Exclude TUs that cause problems in a build where all of QtCore's .cpp
files end up in a single unity_0_cxx.cxx. This should ensure that the
build will forthwith not fail because someone added a new .cpp file in
the "wrong" position.
Of course, this is just a snapshot, with my configuration: GCC 13,
Ubuntu 20.04, -developer-build, C++23, -sctp.
Task-number: QTBUG-115352
Change-Id: If33a485b697f60a2f4d6198f0798c953fa47af51
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit a07426d23a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When we reset the theme so that icons should be provided by the
system theme, then reset the search paths to the system-provided
paths as well. Otherwise we'll keep looking for the system theme
in user-provided search paths, which can't work.
Change-Id: I10bcb404db9924e038f6fdc8970e53bbb69ac7d1
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit e1a93b3d9a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
As a drive-by, re-use the result from the first QFile::exists
check.
Change-Id: I6b36b165ba3d1f82c9b4be18d44a671f71e8507e
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
(cherry picked from commit 510224f446)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Amends a452e22546. No new tests, existing
tests fails when QPlatformTheme returns a QIconEngine implementation
that provides the tested icons. However, the existing test fails when
the platform icon engine provides and address-book-new icon, and depends
on the order of test functions, as the name() test function modifies the
global theme name and search path. Fix those issues in the test.
Change-Id: Ie1c1d14f08fad5e906296bab662df5cfacdbbf07
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit cb16ba5980)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Extract Method create_impl() with all the stuff that doesn't depend on
create()'s template arguments, which will reduce compile time and
amount of generated code.
Change-Id: I9d8f59c168873ac3527b570ef6142079824061cf
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit dc7820a296)
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Looping over the entries had a typo in it and was quite unnecessary,
as it just made a fresh copy of a list we already had.
Change-Id: I0f3023b06163e5854d425d816e465785cda5fc91
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit 07e4015687)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
If the path where Qt sources are located has 3rdparty in it we skip
headers processing since all headers are treated as 3rdparty.
Use path relative to the source directory when indentifying the 3rdparty
header files using regex.
Fixes: QTBUG-115324
Change-Id: If97328cb9a9ece01d43c56022f4613da9b29c03f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit ea4a3d78a7)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
They have no preconditions and cannot throw.
As a drive-by, merge the definition of isEmpty() into its declaration.
Change-Id: Ifffa0d4cb2a285bb802d39d10a757be9c31cfae1
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit 464461dea6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Use it in QMetaCallEvent, to have some automatic test coverage. Other
code that might benefit has undergone changes since 5.15, so will be
ported one-by-one to avoid conflicts on cherry-picks.
Change-Id: I566bab1803e3675f75a9fdf294a4b0f047d21c11
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit c58074b42d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>