We can now get qt_configure_strs to tell us the size of the string, as
well as its start, bypassing the strlen()-calling branch of
fromLocal8Bit() that caused the need for a hack using a volatile
variable. However, QT_CONFIGURE_SETTINGS_PATH still needs the volatile
hack.
Change-Id: I0181abf512123e6355acdd506d6845c3fb75c0e3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Commit 6cee204d56 introduced overloads
of lastIndexOf() which drop the 'from' argument, inadvertently fixing
QTBUG-80694, but failed to provide the new overloads for all existing
lastIndexOf() overloads, making the fix for QTBUG-80694 incomplete.
This patch completes the fix, by adding the missing overloads (for
char-likes) and also adds the missing (non-regex) tests to
tst_qstringapisymmetry.
Also amends 1c164ec7f2.
Fixes: QTBUG-80694
Change-Id: Ib4b3d597d658ce2edf01a2bce0d711ecea593d6e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
cmake_automoc_parser has the logic preventing the run of moc with the
--collect-json parameter if metatype json files are not changed.
This logic only verify if the file list is changed but not their
content. This change adds a timestamp file that contains the last
metatype json file timestamp that was modified during the last
cmake_automoc_parser run. The logic still prevents of running
'moc --collect-json' when the list of metatype json files is not
changed, but also checks if their content is no changed.
Another approach it to generate the depfile that can be utilized by
CMake in add_custom_command as DEPFILE argument. But this concept only
works from the second build attempt because of an issue related to
dyndep.
Pick-to: 6.2
Fixes: QTBUG-98532
Change-Id: I713f8bfa9ae769cefe0beac0b7fa19750b00a765
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Encapsulate configuration options in a function and use it instead of
a globally defined variable.
Pick-to: 6.2
Change-Id: I5c69c207788fe069fdd046b68a6bc58aa16e71b4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qt_internal_${target}_copy_apk_dependencies should use CMake DEPFILE
approach when it's possible. Since we don't have any specific
artifact that androiddeployqt can produce when collecting dependencies
this change adds simple timestamp file that is touched each time when
androiddeployqt is running. The timestamp is used then as a file-level
dependency for the qt_internal_${target}_copy_apk_dependencies target.
Task-number: QTBUG-88841
Change-Id: I985535c7b6e471cb4cfbf90128628087dadc72d0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Instead of generating external projects that build the project tree
for each target, this creates a single project for each ABI that have
the common for all targets configure steps. Each executable target
then adds additional build step to each ABI-specific external project,
that builds and copies dependencies to the "main" project build tree.
To resolve dependencies from the build tree, when building multi-abi
apk instead of scanning the build directories of external projects for
dependencies, it makes sense to run androiddeployqt for each
ABI-specific external project to copy all necessary libraries. This
is done by adding --copy-dependencies-only flag to androiddeployqt
that only copies the apk dependencies, but avoids creating apk and all
the essential steps. The ABI-specific external project now handles the
deploying of the build artifacts to the end-point apk deployment
directory and the "main" project assembles the apk using collected
artifacts. The ABI-specific external project uses the
qt_internal_${target}_copy_apk_dependencies target to run androiddeployqt
with the introduced --copy-dependencies-only flag.
TODO: Build steps that build and copy the ABI-specific apk
dependencies are non-skipable and will run each time top-level build
is triggered. This behavior should be fixed by adding dependencies to
the generated by androiddeployqt DEPFILES for each ABI in the
top-level build.
Task-number: QTBUG-88841
Tash-number: QTBUG-94714
Change-Id: Id442a9fbd589f58b70f4204c5215645056b379a2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
And mention the example in the bindable properties docs.
Pick-to: 6.2
Task-number: QTBUG-97655
Change-Id: I676e90dbda66c2e718c7f6c2240fac608a8653df
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Cleaner. Probably also more efficient at compile time, who knows?
Also more consistent, since _some_ static if's were already
constexpr'ed.
Change-Id: I9657f7cf2166975f562db52e9f90630aaf412986
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Two more instances where we can use public API instead of accessing the data members directly.
Amends 9d79e5f26c.
Task-number: QTBUG-84785
Change-Id: I2037339383836b0d292b3362fe1d6b056638e81a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
ABI-specific external projects should use the same config as the one is
used by the "main" ABI.
Task-number: QTBUG-88841
Change-Id: If7a1834d9a3f238f6dadd05323ccc0cf8552128c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
std::function, which is used to store the type-erased continuation
lambdas, requires the passed callable to be copy-constructible. This
makes impossible to use move-only callables with continuations/handlers.
In particular, it makes impossible passing lambdas that are capturing
move-only objects. The workaround is to store the continuation lambda
inside a wrapper for the callable, which stores the move-only lambda in
a QSharedPtr and can be stored in std::function, since it's copyable.
Pick-to: 6.2
Fixes: QTBUG-98493
Change-Id: I8b7a22fcf68dc132b3c533216a7a1665e9f9fb0a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Instead of calling the QVLA(qsizetype) ctor and letting the optimizer
and inliner have a field day on them, simply set the trivial values
for a, s, and ptr manually.
Mark it as noexcept.
Task-number: QTBUG-84785
Change-Id: I011826eacdaf63a4c37b21465e5fe4a6e70a1ab7
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
According to the CMake documentation any relative paths in DEPFILE
should be relative to the CMAKE_CURRENT_BINARY_DIR if the CMP0116
is set to NEW. This also forces CMP0116 to NEW if the policy exists.
Pick-to: 6.2
Change-Id: I3d697b008ea06effb2247bc204da9bcc4e9046b4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add target triggering AAB creation. Since the _make_aab target is
not added to the ALL set, we may avoid dependency check for it and
admit that the target is "always out of date".
[ChangeLog][Android][Platform Specific Changes] Add the extra
_make_aab targets for each executable target, that can be used
to generate android app bundles. Also add aab metatarget to build
all _make_aab targets that are created in the project.
Pick-to: 6.2
Fixes: QTBUG-96710
Change-Id: I3b0c7fbb5a7dd493ca7a124c4e4b91fd857386bd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The only documented replacements for Q*String*::arg() are sequences like
%1, %2, %3 -- where the n-th number is expressed using a sequence of
ASCII digits [1].
The code parsing the replacements however used the QChar::digitValue()
function. That function simply checks if a QChar has a *Unicode digit
value* (no matter what its block/category is), and if so, returns the
corresponding digit value as an int (otherwise returns -1).
The result of this is that a sequence like "%¹" or "%१" actually
triggered substitutions (both count as "1"). Similarly, QChars with
a digit value would be parsed as part of longer sequences like "%1²"
(counting as "12" (!)).
This behavior is weird, undocumented, and extremely likely the usual
backstabbing by Unicode by using "convenience" QChar methods -- that is,
never *intended* by the implementation.
This commit deprecates (via warnings) such usages, which for the time
being are left working as before (in the name of backwards
compatibility). At the same time: given it's extremely unlikely that
someone would be deliberately relying on this behavior, it implements
the desired change of behavior (only accept sequences of ASCII digits)
starting from Qt 6.6, that is, after the next LTS.
Throughout Qt 6's lifetime users will still be able to control arg()'s
behavior by setting an env variable, but that variable (and the support
for Unicode digits) will disappear in Qt 7.
To summarize:
* Qt 6.3->6.5: default is Unicode digits, env var to control
* Qt 6.6->6.x: default is ASCII digits, env var to control
* Qt 7: only ASCII digits, no env var
[1] That's the name Unicode gives to them, cf. https://www.unicode.org/charts/PDF/U0000.pdf
[ChangeLog][QtCore][Deprecation Notices] The arg() functions
featured in Qt string classes have always been documented to require
replacements tokens to be sequences of ASCII digits (like %1, %2, %34,
and so on). A coding oversight made it accept sequences of arbitrary
characters with a Unicode digit value instead. For instance, "%2੩" is
interpreted as the 23rd substitution; and "%1²" is interpreted as the
12th substitution. This behavior is deprecated, and will result in
runtime warnings. Starting from Qt 6.6, arg()'s behavior will be changed
to accept only ASCII digits by default. That means that "%1²" is going
to be interpreted as substitution number 1 followed by the "²" character
(which does not get substituted, so it gets left as-is in the result).
Users can restore the previous semantics (accept Unicode digits) by
setting the QT_USE_UNICODE_DIGIT_VALUES_IN_STRING_ARG environment
variable to a non-zero value. In Qt 7, arg() will only support sequences
of ASCII digits. Note that from Qt 6.3 users can also set
QT_USE_UNICODE_DIGIT_VALUES_IN_STRING_ARG to zero; this will make arg()
use ASCII digits only, in preparation for the future change of defaults.
Change-Id: I8a044b629bcca6996e76018c9faf7c6748ae04e8
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
QtCreator doesn't expect any config-specific suffixes in the android
deployment settings file, when running androiddeployqt. This avoids
adding the config-specific suffix in the single-config builds and
for the first config in the multi-config builds.
Amends a41d9bcac9
Change-Id: I606509c9bfd2e75cac144aca37b4568639aae74f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In QNX, instead of #include <elf.h>, we have to use #include <sys/elf.h>
since that file is placed in a subdirectory.
Also removed the previous workaround.
Fixes: QTBUG-97833
Change-Id: Id932a5eeb618a42c8778459cdfd8bb5bf903523c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
std::tie(a, s, ptr) = {Prealloc, 0, (T*)array} is exactly the effects
of the default ctor, so just delegate to it, before calling
copyAppend().
Also clean up the copy ctor declaration (superfluous inline keyword,
and template arguments).
Change-Id: Iefc758a47996382fee10b1e081e44f008b146287
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use data() and data() + size() instead.
This solves an UB when the list is in its default-constructed state,
for which constData() == nullptr.
Pick-to: 6.2
Fixes: QTBUG-98770
Change-Id: I2cffe62afda945079b63fffd16bc165978c769f6
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Convenience getters for mime type associated with the object.
Change-Id: I7e3530459e50ac4740d533db59c46e838c94dbcd
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
... just to pass it to pcre2_compile_16().
The QString::utf16() function guarantees a NUL-terminated result, so
it detach()es from QStringLiteral (Qt 6) and/or QString::fromRawData()
(Qt 5 + 6).
This user doesn't require the NUL-termination, though, since
pcre2_compile_16() takes an explicit length, so the detach() is
completely unneccesary, yet common, since regex pattern strings are
often QStringLiteral()s.
Task-number: QTBUG-98763
Change-Id: I1d08ae1a1ec4281ff44a68c5ba5c56584b71d24e
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
... instead of QT_PREPEND_NAMESPACE(qHash), which is qualified (prepends at least '::'), and therefore disables ADL.
This is not a problem as long as we wrote our qHash() overloads as free functions (incl. non-hidden friends), but it should™ fail for hidden friends, so use the old using-std::swap() trick to bring QT_PREPEND_NAMESPACE(qHash) into scope, proceeding with an unqualified lookup.
Pick-to: 6.2
Change-Id: I00860b2313699849f86bfe3dd9f41db4ce993cd3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The old-syle signal-slot syntax had the advantage of not delivering
signals to slots in derived classes after that derived class's
destructor had finished running (because we called via the virtual
qt_metacall). The new syntax made no checks, so a conversion from the
old to the new syntax may introduce crashes or other data corruptions at
runtime if the destructor had completed.
This commit introduces a Q_ASSERT to print the class name that the
object is not any more. Since this is in inline code, this should get
enabled for users' debug modes and does not therefore depend on Qt being
built in debug mode.
It required some Private classes to be adapted to the new form, by
exposing the public q_func() in the public: part.
Pick-to: 6.2
Fixes: QTBUG-33908
Change-Id: Iccb47e5527544b6fbd75fffd16b874cdc08c1f3e
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Happens on line:
return QList<QLocale>() << QLocale(QLocale::C);
QLocale's constructor taking the C "language" calls findLocalePrivate()
that returns indeed the non-heap object c_locale in the c_private()
function. But it also sets the refcount to 1, meaning it can never drop
to 0 under proper refcounting and will thus never be deleted.
Therefore, the compiler is wrong. I don't have time to figure out how to
teach it that the deletion can never happen. I just want the warning to
go away. It wsa probably introduced by commit
d4242b8af3.
In destructor ‘QSharedDataPointer<T>::~QSharedDataPointer() [with T = QLocalePrivate]’,
inlined from ‘QLocale::~QLocale()’ at /home/tjmaciei/src/qt/qt6/qtbase/src/corelib/text/qlocale.cpp:1035:1,
inlined from ‘void QtPrivate::QMovableArrayOps<T>::emplace(qsizetype, Args&& ...) [with Args = {QLocale}; T = QLocale]’ at /home/tjmaciei/obj/qt/qt6/qtbase/include/QtCore/../../../../../../src/qt/qt6/qtbase/src/corelib/tools/qarraydataops.h:829:5,
inlined from ‘T& QList<T>::emplaceBack(Args&& ...) [with Args = {QLocale}; T = QLocale]’ at /home/tjmaciei/obj/qt/qt6/qtbase/include/QtCore/../../../../../../src/qt/qt6/qtbase/src/corelib/tools/qlist.h:891:15,
inlined from ‘void QList<T>::append(QList<T>::rvalue_ref) [with T = QLocale]’ at /home/tjmaciei/obj/qt/qt6/qtbase/include/QtCore/../../../../../../src/qt/qt6/qtbase/src/corelib/tools/qlist.h:479:24,
inlined from ‘QList<T>& QList<T>::operator<<(QList<T>::rvalue_ref) [with T = QLocale]’ at /home/tjmaciei/obj/qt/qt6/qtbase/include/QtCore/../../../../../../src/qt/qt6/qtbase/src/corelib/tools/qlist.h:726:13,
inlined from ‘static QList<QLocale> QLocale::matchingLocales(QLocale::Language, QLocale::Script, QLocale::Territory)’ at /home/tjmaciei/src/qt/qt6/qtbase/src/corelib/text/qlocale.cpp:2684:54:
/home/tjmaciei/obj/qt/qt6/qtbase/include/QtCore/../../../../../../src/qt/qt6/qtbase/src/corelib/tools/qshareddata.h:91:55: warning: ‘void operator delete(void*, std::size_t)’ called on unallocated object ‘c_locale’ [-Wfree-nonheap-object]
91 | ~QSharedDataPointer() { if (d && !d->ref.deref()) delete d; }
| ^~~~~~~~
Pick-to: 6.2
Change-Id: Iccb47e5527544b6fbd75fffd16b8d078987b812b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The qHash(QSharedPointer) implementation is already in QT_NAMESPACE,
if any, so explicitly qualifying the call adds no functions to the
overload set, but actually removes functions that would be found by ADL
(which is only enabled for unqualified calls).
Fix by using an unqualified call.
[ChangeLog][QtCore][QSharedPointer] The qHash(QSharedPointer<X>)
overload can now use qHash(X*) overloads found (only) through ADL
(was: ADL was disabled due to qualified lookup of qHash(X*)).
Pick-to: 6.2 5.15
Change-Id: Ic6cc47103142d48b6cdefa2cd6552a65cf1cb222
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Add Uint8Array::copyFrom() and Blob::copyFrom(), which
constructs JS data containers with content copied from
the C heap.
These should not be confused with e.g. the Uint8Array(buffer, size)
constructor, which creates a Uint8Array which references
content on the heap, without making a copy.
Change-Id: Id7d25d8044ee3914d74698e5a15c93226568eaf3
Reviewed-by: David Skoland <david.skoland@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Like Q_NAMESPACE_EXPORT for Q_NAMESPACE, this variant of Q_GADGET
allows passing an export macro. This is useful to avoid exporting the
whole class just to get the staticMetaObject hidden therein exported.
Before anyone asks: No, we don't need Q_OBJECT_EXPORT, because QObject
subclasses, being polymorphic, always need to have a class-level
export macro (to export their vtable), but while that technique also
works for value classes (the Q_GADGET audience), it is not desirable
for them, because it makes inline functions exported in Windows debug
builds, which is not what we want, because it needlessly restricts
what you can to with the inline functions (e.g. remove).
[ChangeLog][QtCore] Added the Q_GADGET_EXPORT macro, which is like
Q_GADGET, but allows passing an export macro (like Q_NAMESPACE_EXPORT
for Q_NAMESPACE).
Fixes: QTBUG-55458
Change-Id: I546297de1e8aa45d83381991bcd3fbca61e1eef0
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It is not immediately clear from the signature that the time parameter's
unit is miliseconds.
Pick-to: 6.2
Change-Id: Ifee3c6410b6b2352e75571cc53578a660aabb32d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Also fix an unrelated minor issue in QtFuture::whenAll docs.
Task-number: QTBUG-86714
Change-Id: I45f06b17db0508be10215e6d260ef76ede3077fb
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The declaration of insert(it, n, t) used qsizetype for n, while the
definition used size_type. That works by chance, because the size_type
typedef comes only after the insert(it, n, t) declaration. It was
detected when size_type became a typedef in a base class of
QVarLengthArray in my local branch.
Just use the same type name in the implementation as in the
declaration.
In 5.15, the same issue exists (with s/qsizetype/int/).
Pick-to: 6.2 5.15
Change-Id: I64235eeaeaed3d43f4c070ca536474fae94c1b5d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
In qt6_android_add_apk_target we require that ${target} is already
defined. So to add custom command that runs androiddeployqt we may
simply read BINARY_DIR property of the target and use it as path to
generated apk file as OUTPUT argument. This avoids the use any
intermediate paths when producing apk and related artifacts.
Change-Id: I8bb4174f6f9696e7a2a6b5d6399bb410419495fc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QAbstractProxyModel::itemData/setItemData should behave
just like data()/setData() instead of calling the
QAbstractItemModel implementation.
Before this change the QAbstractProxyModel implementation
calls its the QAbstractItemModel implementation,
which ends up calling data()/setData() in a loop
bypassing the convenience of itemData/setItemData.
[ChangeLog][QtCore][QAbstractProxyModel] The itemData()
and setItemData() functions will now call the respective
implementations in the source model (after mapping the
index to a source index), matching what data() and
setData() already did.
Before, the proxy model simply called the default
implementations of itemData()/setItemData() in its own
base class (QAbstractItemModel).
Change-Id: I9e680d355f44fa130660dd7e1c8ac37484c1566e
Reviewed-by: David Faure <david.faure@kdab.com>
This function is useful also outside of local file access,
for example when reading clipboard (file) content.
Change-Id: I132546deb6df2969467051c348c05d9331d2cfd2
Reviewed-by: David Skoland <david.skoland@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Use new QDir::mkdir() method to set directory permissions at the time
of its creation on systems that support this feature. This removes the
time window when the created directory is potentially accessible to
everybody.
Task-number: QTBUG-79750
Change-Id: I82afee7f0708bfdcc9b3b3978af9a2aef1b8672d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This patch adds an overload of the QDir::mkdir() method that
accepts permissions. This allows setting of the directory
permissions at the time of its creation.
[ChangeLog][QtCore][QDir] Added QDir::mdkir() overload that
accepts permissions argument.
Task-number: QTBUG-79750
Change-Id: Ic9db723b94ff0d2da6e0b819ac2e5d1f9a4e2049
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Q(Multi)Map mutating functions that take reference to a key and/or a
value (e.g. insert(), take(), etc.) must make sure that those references
are still valid -- that is, that the referred objects are still alive --
after the detach() call done inside those functions.
In fact, if the key/value are references into *this, one must take extra
steps in order to preserve them across the detach().
Consider the scenario where one has two shallow copies of QMap, each
accessed by a different thread, and each thread calls a mutating
function on its copy, using a reference into the map (e.g.
map.take(map.firstKey())). Let's call the shared payload of this QMap
SP, with its refcount of 2; it's important to note that the argument
(call it A) passed to the mutating function belongs to SP.
Each thread may then find the reference count to be different than 1 and
therefore do a detach() from inside the mutating function. Then this
could happen:
Thread 1: Thread 2:
detach() detach()
SP refcount != 1 => true SP refcount != 1 => true
deep copy from SP deep copy from SP
ref() the new copy ref() the new copy
SP.deref() => 1 => don't dealloc SP
set the new copy as payload
SP.deref() => 0 => dealloc SP
set the new copy as payload
use A to access the new copy use A to access the new copy
The order of ref()/deref() SP and the new copy in each thread doesn't
really matter here. What really matters is that SP has been destroyed
and that means A is a danging reference.
Fix this by keeping SP alive in the mutating functions before doing a
detach(). This can simply be realized by taking a local copy of the map
from within such functions.
remove() doesn't suffer from this because its implementation doesn't do
a bare detach() but something slightly smarter.
Change-Id: Iad974a1ad1bd5ee5d1e9378ae90947bef737b6bb
Pick-to: 6.2
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The old code attempted to detect the overflow of the requestCode
variable, but because it didn't do anything about it except warn, it
still ran into the overflow, and, since the variable is signed, into
UB. That means that a clever compiler will just eliminate the warning
as dead code because it can backtrack and see that the condition
guarding it is never true, because otherwise UB happens.
Fix that problem by using a uint counter (unsigned overflow is defined
to wrap) and only convert to int after the check.
Also fix two inefficiencies with the old code:
1. We don't need a mutex just to up a counter in a thread-safe
way. Upping a shared counter is the prototypical use-case for
relaxed atomics, so use that. That also solves the problem of the
non-POD static object at function scope (QMutex) that forced
compilers to emit thread-safe static initialization code.
2. We had a static variable whose initial value isn't 0, which means
it can't be in stored in the BSS, but only in the DATA segment. Do
the trivial transformation of subtracting the offset so the
variable starts at 0. The offset can be added afterwards.
Pick-to: 6.2
Change-Id: I3560df21d6b4e4201cb6772237780cc8b400631d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The command-pair was recently deprecated.
The replacement code should produce an output that is equal to the
previous one.
Task-number: QTBUG-98499
Change-Id: If26e0d85a174ebc3858b638c34d7f43637eab46d
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
If we detach from a shared hash while holding a reference to a key from
said shared hash then there is no guarantee for how long the reference
is valid (given a multi-thread environment).
Pick-to: 6.2
Change-Id: Ifb610753d24faca63e2c0eb8836c78d55a229001
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The qobject.h header needs QBindingStorage in-size and QBindable
in-name-only. The former was moved to its own header in a previous
commit, which we include now, while the latter can just be
forward-declared. This allows dropping the qproperty.h include from
qobject.h.
[ChangeLog][Potentially Source-Incompatible Changes] The qobject.h
header no longer implicitly includes qproperty.h. If your code depends
on the transitive include, explicitly include <QProperty> where
needed.
Task-number: QTBUG-97601
Pick-to: 6.2
Change-Id: I8d6320f5978e20dfc394d2b1e49f626b99529c37
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It won't change during runtime, so make it a static
variable to avoid fetching the information repeatedly.
Change-Id: I430ceba218f9f3515558736238d1d5a74cf59419
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Warning was:
"QtCore: WARNING: src/corelib/kernel/qapplicationstatic.h includes QMutex when it should include QtCore/QMutex"
Comply.
Change-Id: Ifc74b4f8052b7e95f86cab9a01a7e91bcbc3022d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Use member functions to access some (combinations of) fields in
preparation of moving said fields to base classes:
s + ptr → end()
s → size()
ptr → data() (or begin(), depending on context)
a → capacity()
Fixed a const-incorrectness issue detected by the change.
Task-number: QTBUG-84785
Change-Id: I2218d57559208c9d77b8860d419979e92f140e13
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][QtCore] Added QtFuture::whenAll() and QtFuture::whenAny()
functions, returning a QFuture that becomes ready when all or any of the
supplied futures complete.
Task-number: QTBUG-86714
Change-Id: I2bb7dbb4cdc4f79a7a4fd494142df6a0f93a2b39
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Commit 2549a88ba2 changed the ELF and
Mach-O parsers to return an offset to the actual data header, not the
magic string, which we stopped searching for anyway. This commit brings
such a validity check back and adds it to the new COFF PE parser.
Change-Id: Iccb47e5527544b6fbd75fffd16b8b2252a76f179
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
No need to attempt to compile both qelfparser and qmachoparser in all
systems.
Change-Id: Iccb47e5527544b6fbd75fffd16b7ee5a1555a7a8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This reverts commit 1283ee3245.
We now have wrappers around std::mutex and std::condition_variable
that fall back to QMutex and QWaitCondition on the broken Integrity
toolchain. Use them.
Change-Id: I881aa931167b845b489713048b57ccc5f79d4237
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Extract the definition of q20::ssize() from tst_qanystringview.cpp,
where it had to be placed for its backport to 6.2.
Change-Id: I3f758c98a4b1efd453f4fc044b8d3f1a89de62d1
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Edward Welbourne
Marc Mutz
Alexey Edelev
Sona Kurazyan
Giuseppe D'Angelo
Janne Juntunen
Thiago Macieira
Lorn Potter
Morten Johan Sørvig
Fabian Kosmale
Luca Beldi
Ievgenii Meshcheriakov
Luca Di Sera
Mårten Nordheim
Yuhang Zhao
Marc Mutz