The deprecated implementation of QSharedMemory and QSystemSemaphore
are not correctly guarded by the deprecation macros, and thus it's
causing compilation errors when we disable deprecated code.
As a drive-by, change the deprecate version from 6.9 to 6.10
as requested.
Change-Id: Icfed181c27248b9e1381101a64523419097dd1da
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Removed `_DEFAULT_SOURCE` as it was not consistent, and possible didn't
work in the first place, and was masked by the exclusion of
`io/qfilesystemengine_unix.cpp`.
Amends fc3a9ee601.
Pick-to: 6.5
Task-number: QTBUG-109394
Change-Id: I8036e66d29d5ec88608d284436b4e8719144f06d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add export to be consistent with the declaration in
qdbusxmlgenerator.cpp.
Pick-to: 6.5
Task-number: QTBUG-109394
Change-Id: I08c915a7ee737617388db4c0d1a3d116cb8bc3a1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's documented to return -1 when the file doesn't exist, so we gain
nothing by saying a file we ourselves must have created doesn't exist.
Change-Id: I12a088d1ae424825abd3fffd171dfa1de6705787
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This collides with a similarly name struct/object in qmutex.cpp.
Pick-to: 6.5
Task-number: QTBUG-109394
Change-Id: I29404f092db523e21f310b4e5b3cd8cc35170e4a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
They were leftovers from QTDS driver removed with Qt6
Change-Id: I34863912bd41e0b4ca54bf443001f1cb3f20511a
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
And on 64-bit platforms, use a 64-bit integer, which removes a
subtraction from the matching code.
The loop in bytearrayToLongLong() looks like, on x86-64:
movabsq $4294983168, %rsi
.L1217:
movzbl (%rdx), %ecx
cmpl $64, %ecx
ja .L1216
btq %rcx, %rsi
jnc .L1216
incq %rdx
cmpq %rbx, %rdx
jne .L1217
Change-Id: I3d74c753055744deb8acfffd1723d8b51e151432
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It now generates its valgrind.h from a valgrind.h.in, but there were
only two @...@ tokens to substitute, so that was easy enough.
From reading the diff, important changes:
* Added x86 support on FreeBSD (32- and 64-bit)
* Added nanoMIPS support on Linux
* Inline assembly fixes for S390
* Added VALGRIND_CLO_CHANGE request
Pick-to: 6.5
Task-number: QTBUG-110999
Change-Id: I66990c958cf40c34e7d58dd60b1e11984303fb64
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Replace qlocaltime.cpp's qt_tzname() with qTzName() in
qtenvironmentvariables{_p.h,.cpp} so as to put the access to the
standard library global under the control of the same lock as controls
all Qt's calls to tzset() and functions that behave as if they called
it. This avoids UB on access to the global during a call to any of
these functions. Take care to use the lock only for the shortest time
needed.
This simplifies both callers and lets a QDTParser method escape to
qdatetimeparser.cpp to become a simple local static function instead
of a class method defined in a separate compilation unit.
Change-Id: I5ddee5641f2ed7b5676ece10375a1d5232eb7f22
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We so far refetched the first observer after evaluating bindings, as
binding evaluating might change the list of observers.
However, that approach did not take into account that the 'this' pointer
might no longer be valid after binding evaluation: In case of a
QObjectBindableProperty (or a QObjectCompatProperty), binding evaluation
might cause a reallocation of the binding storage, and consequently the
invalidation of the QPropertyBindingData.
Fix this by refetching the QPropertyBindingData from the storage (if a
storage has been provided, which is always the case for the affected
classes).
Fixes: QTBUG-111268
Pick-to: 6.5 6.4 6.2
Change-Id: Ie7e143a0bbb18f1c3f88a81dd9b31e6af463584f
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
To suppress the generation of the Ui class within QT_BEGIN_NAMESPACE
and QT_END_NAMESPACE.
Change-Id: I6552b41d8e9eccb0475618d7ed7f7cea7f826625
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This is for internal use, QRhiShaderResourceBinding does not need
to have the data() getters. The backends can use any internal means
to access this, no need to have the getters in the frontend just for
that.
Now, Qt Quick 3D has a special case of accessing this, hence keeping
the two getters for now, to be removed in a follow up once that repo
updates.
While we are at it, share and reuse the sorting function.
Change-Id: Ia2308af79863c72ca65024ce6c00531d0256a2cb
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Also bring all list-like data to the same level when it comes
to the interface exposed in QRhi*.
Change-Id: I90296a49ff1f52c1ce4e787167c99006fab3c4c3
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
This does not really belong here as a built-in feature, esp.
considering that such testing is relevant for other backends
as well.
Change-Id: Ifbe3b8c6a430aacb9fcbdabf0e3761b14c48decc
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
The QtSql for Mimer SQL sqldriver makes it possible to work with the
Mimer SQL database on different plattforms. There are drivers for
several other databases in QtSql and a driver for Mimer SQL will
benefit many users.
To build the Mimer SQL driver, download Mimer SQL from
https://developer.mimer.com
[ChangeLog][QtSql]
Added a QtSql plugin to work with the Mimer SQL database
Fixes: QTBUG-111219
Change-Id: Id6ba5de4de01189d0516ffbfa89efcb0d013115f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Drive-by change: use UTF-16 instead of UTF-8 for Eastern Arabic
Numerals, both are not human-readable but UTF-16 is one code point
instead of the two for UTF-8, less \x.
Pick-to: 6.5
Change-Id: I721f3989b7d776ddc4f9d337b21dca9d398fcc0d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Constructing from const char* etc is already covered by
constructorQByteArray.
I took a guess that the "// b(10)" comment is about testing constructing
a QString from a QChar[] that has an explicit \0 charcater. I tried
finding what the initial intent was but the trail went cold at the
"Initial import from the monolithic Qt" commit.
Pick-to: 6.5
Change-Id: I15bcdb24e55286eb6cd3056af0714a1eed581635
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Increase to 16GB from 3.5GB. Increase to 6GB was not enough.
Increase to 16GB fixed tst_QByteArrayLarge cases failures.
Task-number: QTQAINFRA-5391
Task-number: QTBUG-108832
Pick-to: 6.5
Change-Id: I97e263fbc2caa7908c706d1c683a4fa868afa7b6
Reviewed-by: Heikki Halmet <heikki.halmet@qt.io>
Adding the toolbar to the main window leaves it up to the main window
how to handle ownership and placement of the toolbar.
Pick-to: 6.5
Change-Id: Id429cbad9d5973931a86fcb899684e3651694fbb
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
There is concern about string-based connect() source compatibility in
the case that a signal argument has a different type name.
Amends bc857f466d
Change-Id: I2618b8c5f62b39717e4f7043d07168e808390b1d
Pick-to: 6.5
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
If the application executable was built against a pre-macOS 11 SDK, macOS
will report its version as 10.16 on every OS from macOS 11 and up, for
compatibility reasons.
From Qt 6.2 and up, we require at least Xcode 12 with the macOS 11 SDK
to build Qt applications, so normally this should not be an issue, but
in the case where the Qt 'app' is a plugin library hosted by a third
party host application, the host application determines the behavior,
and we might end up in the compatibility situation after all.
However, since the Qt app was built against at least the macOS 11 SDK,
we know that it can/should handle the new version number scheme, and
we can resolve the real version number for QOperatingSystemVersion.
We do that by launching the sysctl binary with the SYSTEM_VERSION_COMPAT
environment variable set to 0, which is the supported way of disabling
the compatibility mode.
Now that we have the real version number we can use that for the
deployment target check via qt_apple_check_os_version(), but we
still need to account for possible failures in reading the plist
file.
We can also simplify the QOperatingSystemVersion::MacOSBigSur
definition, now that we always know the app the should be able
to handle major versions above 10.
Pick-to: 6.5 6.4 6.2
Task-number: QTBUG-111114
Change-Id: I2a2756381c31b195f7b8800c5008a87b37114080
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Otherwise, double-click recognition will fail.
Use QEvent::clone when possible, or set the timestamp explicitly when
not.
As a drive-by, remove some long-dead code in affected code lines.
Fixes: QTBUG-102010
Pick-to: 6.5 6.4 6.2
Change-Id: I882bf6e8090bf6f182b7a0a3c62aa3a4c8db2e14
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Most keyboards today do not have a dedicated Meta key. Instead, they may
have a Win key (Windows logo, Penguin logo, etc), which is delivered by
evdev as e.g. KEY_LEFTMETA, but then mapped by libxcbcommon to LWIN
via the default config from xkeyboard-config:
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/master/keycodes/evdev#L203
and then mapped further to Super_L
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/master/symbols/pc#L24
which is the key symbol that we in Qt see.
As it is common to use Qt::Key_Meta in keyboard shortcuts, it would
be useful if the Win key resulted in key events as if a dedicated Meta
key had been pressed.
This is already something we do for X11, where we consume the events
from xkbcommon, but then use X-specific heuristics to determine if
there is an actual Meta key, and if not, we assume Super/Hyper is Meta.
For plain xkbcommon, we don't have enough information to do the same
kind of heuristics, so we've previously defaulted to not treating
Super/Hyper as Meta. But, as the above xkeyboard-config configs show,
a saner default would be to assume that there is no Meta key, and do
the same mapping as we do for X11 for all consumers of xkbcommon,
such as Wayland and EGLFS.
This does mean that clients that were relying on dedicated Super or
Hyper keys producing Qt::Key_Super or Qt::Key_Hyper will no longer
see these keys being pressed.
[ChangeLog][QtGui][Linux/Wayland][Linux/Yocto] Super ("Win" key) and
Hyper keys will no longer produce the corresponding Qt::Key_Super or
Qt::Key_Hyper key events, but will instead be mapped to Qt::Key_Meta
and result in Qt::MetaModifier being set.
Fixes: QTBUG-62102
Change-Id: Ied4c8b60a0639e87116ab70c7e40d4082f52b18d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Replace local built-time enabled macro with a logging category.
As a drive-by, move QDebug streaming operator into the anonymous
namespace to prevent external linkage, break some excessively long
lines, and remove dead code.
Task-number: QTBUG-102010
Pick-to: 6.5 6.4 6.2
Change-Id: I49d212ee4a66a3eabfa5567f6c8d9674ffbb8880
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The [first, first+n) and [out, out+n) ranges cannot possibly overlap, as
by definition the former contains live objects while the latter points
into uninitialized storage. So we can use memcpy here, and not memmove.
Change-Id: I4a1b39f73ffa67915c5252938554f45f4444293e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
I.e. the second arg to QCOMPARE isn't what's being tested.
Drive-by changes:
- More _L1 usage, less blocky and easier to read
- QCOMPARE's second arg can be a View, it is smart enough and can
compare them just fine
- Replace a "//15 chars" comment with a QCOMPARE check
Pick-to: 6.5
Change-Id: I4f4b84b16b543df37b0ba2f9dd781b045b2ed397
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Document the potential issue caused by using QT_ANDROID_EXTRA_LIBS from
the project build tree.
Inspired by QTBUG-111173.
Pick-to: 6.5
Change-Id: I39fcda6e19b15eb13a390978230944dad41ec8d1
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
As of macOS 10.14 the keyboard assistant background is shipped as part
of the compiled asset catalog of the app, so looking it up via a URL
will fail.
Instead we look it up via NSBundle's dedicated image lookup function,
which handles both cases.
The logic has also been moved to qwizard.cpp, since the additional
plumbing via QPlatformNativeInterface was unnecessary.
The keyboard assistant itself no longer shows the background image
as of macOS 12, so we might consider doing the same, but the design
of the assistant has also changed significantly, so as long as our
QWizard layout looks like the old keyboard assistant we keep the
background as well.
Pick-to: 6.5 6.2
Change-Id: I7d42dd79b285f3518837458864bca6bc353b3b6d
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This reverts commit 545400addd.
Reason for revert: Adding NO_CMAKE_PACKAGE_REGISTRY doesn't resolve the initial issue. So reverting this change as redundant.
Change-Id: I284600d6f0e0f2408a7a8b31827251dad4c73eba
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This feature should not be needed in most wasm applications.
Disabling it by default can save ~50KB in QtQuick apps.
Task-number: QTBUG-110843
Change-Id: Iac0a51bfd016db1da40b59ed32e3faf6ad4267e0
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Application delivered via the macOS or iOS App Store might have their
libraries encrypted, in which case we can not read any of the sections
of the binary until it has been dlopened.
This was causing issues for our plugin loading code, which assumed we
could read the .qtmetadata section of a yet to be loaded plugin to
determine its suitability, before loading it.
We now detect whether a library is encrypted during the Mach-O parsing,
and propagate this back to QLibraryPrivate::updatePluginState(),
which can handle the case by explicitly loading the library before
continuing with metadata validation. We still ensure that the library
has a .qtmetadata section, so that we don't need to dlopen any random
library in our path.
This does mean that we will potentially load more plugins than we
need, and since the Qt version validation happens as part of meta
data validation, we might dlopen() incompatible plugins, but it's
expected that in an App Store deployment scenario you control both
the versioning and set of shipped plugins, so this should not be
an issue in practice.
As encrypted libraries are only produced for apps that are fully
published to the App Store, and then deployed via MDM, VPP, or
Apple Configurator 2, we don't have an easy way to test this,
but the existing code paths should be unaffected, and hopefully
this patch improves the situation for the encrypted library case.
Pick-to: 6.5 6.4 6.2 5.15
Change-Id: Iff733505f7067ce5571854ea978bc95e8376e347
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The QSslCertificate ctor is somewhat expensive, especially when we are
shutting down. By using optional<> we simply reset() it and no longer
need to create a new, valid, certificate.
Pick-to: 6.5 6.4 6.2
Task-number: QTBUG-102474
Change-Id: I514433b0d380dd3ceabbed3a6164f7e3efc490c7
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
- Port macros to QTest data rows in separate unittests
- Move DOUBLE_TEST-related data to toDouble() unittest
- Drop one redundant unittest:
QTest::newRow("const-charstar") << (const char*)0;
Pick-to: 6.5
Change-Id: Ie809895e9f5d58c2d3ec419689f409b55e24fcf7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
