QSet is internally implemented by a QHash. Therefore the change in
reference stability affects QSet, too.
Pick-to: 6.1 6.2
Change-Id: If1879d5a027211bca0beeff16ffbc77f2f4fce26
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Mention change of behavior introduced by 89f7a2759c in the porting
documentation.
Change-Id: I3c282362f5852cc7768e6655fc7b3901d68f2b10
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
It's only Qt::MiddleButton in Qt 6.
Pick-to: 6.1 6.2
Change-Id: Ia68bad910c617993e30e3ed1e117192469ec50eb
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
When a signal/slot connection is broken, it gets added to the
sender's list of "orphaned connections", to clean up later.
This cleanup happens when the sender gets destroyed or as soon as
it emits any signal.
This may cause soft memory leaks in case receivers get destroyed,
and the sender is a long living object and doesn't emit signals
for a while (e.g. QThread).
For some reason, an explicit disconnection cleans up the list
(either by using the QMetaObject::Connection object, or in case
of string-based connect, using a string-based disconnect). This
raises lots of doubts about why having this list in the first
place.
Fix the soft-leak by cleaning up the orphaned connection list when
destroying a receiver.
Note: I still believe that we shouldn't have any "orphaned"
connection list, and rather cleanup on disconnect/deletion
(otherwise, emitting a signal may cause a CPU spike because it
triggers a cleanup). If we allow for any "impredictability" during
signal activation we're just admitting that signals/slots aren't
suitable for e.g. low-latency codepaths. That's why I'm not marking
the problem as fixed.
Original-patch-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Task-number: QTBUG-88248
Task-number: QTBUG-87774
Pick-to: 6.2 6.1 5.15
Change-Id: Id25f67a45dff49f740132a44d36e88740eb12070
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This does not fix all data races that we have in the system yet.
One major issue is the virtual disconnectNotify(), that can be
called from any thread and thus is inherently problematic, as it
can collide with the object getting destroyed at the same time
in another thread.
Pick-to: 6.2 6.1 5.15
Task-number: QTBUG-88248
Change-Id: I9d841eb363b7e4f0de1657aeb8f5340d0fd55190
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This function is/will be used in a few places where we already have a
lock. Temporarily unlocking and relocking invites all kinds of troubles.
By adding a flag we can instead tell the function that we already hold
the lock.
Pick-to: 6.2 6.1 5.15
Change-Id: Ibca089de61133661d5cd75290f2a55c22c5d013c
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Copying a QOrderedMutexLocker is questionable, and would currenly easily
lead to UB. Therefore we delete the copy ctor and copy assignment
operator, and implement well-behaving move operators.
In addition, provide an explicit dismiss method for cases where we don't
want the locker to unlock the mutexes, as they have been manually
unlocked (this could have been implemented previoulsy by using the copy
assignment operator).
Pick-to: 6.2 6.1 5.15
Change-Id: If2a888710e1c74277b28fd3e2939ab26fff0c7ae
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
For user projects we run the static link order check once
'find_package(Qt6 ...)' is called.
If linker can resolve circular dependencies between static libraries
and object files we set the _qt_link_order_matters property of the
Qt::Platform target. This indicates the use of finalizers is not
required and we may rely on CMake-base propagation of resource
libraries and resource object files.
If linker could not resolve circular dependencies depending on
the _qt_resource_objects_finalizer_mode value:
- Finalizer will be called and collected resource objects will be
linked to the target directly.
- Finalizer will be omitted and resource objects will be linked
using the target_sources function implicitly. This only
propagates resource one level up if consumer links the static
library PUBLICly, but all symbols will be resolved correctly
since object files are placed in the beginning of the linker line.
In the CMake version 3.21 we expect that CMake will take care about
the order of the resource object files in a linker line, it's
expected that all object files are located at the beginning of the
linker line.
TODO: Need to confirm that the CMake 3.21 meets the expectations.
Amends 4e901a2f99
Pick-to: 6.2
Task-number: QTBUG-93002
Task-number: QTBUG-94528
Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The kludge previously implemented for handling dates outside the
supported time_t range, by asking for a corresponding date in a year
in the range, had a comment remarking that this is broken due to the
wrong day of the week and, consequently, the placement of DST
transitions, e.g. those scheduled by the last Sunday of a month,
happening on different dates in the year asked about and the in-range
year passed to the system time_t functions.
This can be handled by selecting a year in the time_t range which has
the same pattern days of the week (and length of the year, i.e
leap-ness). That may (particularly for leap years) need to select a
year far from the end of the range (and there may be a change to the
zone's rules between the selected year and the end).
Change-Id: Ia353b2cc7b7d266b7abf80e37cac61544ce95c2d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
System V semaphores are not supported in sandboxed applications,
so when Qt is configured with App Store compliance, or the user
requests POSIX IPC explicitly, we use that instead.
https://developer.apple.com/library/archive/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW24
As the shared memory name limit on Apple platforms is very low,
we have to skip the existing logic for naming, and instead use
a truncated hash of the key. This should still be fine for
avoiding any collisions in practice.
An explicit check for the ENAMETOOLONG error has been added to
catch any cases where they key goes beyond the allowed length.
Sandboxed applications also have an extra requirement that the
key must include an application group identifier. This requirement
has been pushed up to the user and documented, as we don't have
enough information in Qt to know which identifier to use.
Both tst_QSystemSemaphore and tst_QSharedMemory work as before
with both sandboxed and non-sandboxed applications, after removing
some assumptions in tst_QSharedMemory about System V behavior.
Fixes: QTBUG-91130
Change-Id: Iaf1edb36a5d84d69e42ec31471a48d112faa8c6a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The documentation says that if we "pass a URL to the main
executable of a bundle, the bundle as a whole is generally
recognized.". By passing the executable instead of the
bundle we include command line applications that don't
have a app bundle folder (but have an embedded Info.plist).
Pick-to: 6.2 6.1 5.15
Change-Id: I3a2f145c1ec6e16607e9c04baf08678d5dea0b81
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Abort the system move/resise at XCB_INPUT_TOUCH_END.
Limit the behavior only on supported platforms, such as KDE and
OpenBox.
Change-Id: I53c86979ca56f4de8c5cf2807f781abdad6987b2
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
We can't get mouse release event from master pointers after
QXcbWindow::doStartSystemMoveResize() which calls xcb_ungrab_pointer(),
it looks like most X11 WMs work as that.
So we try to get mouse release event from slave pointers.
Based on https://specifications.freedesktop.org/wm-spec/1.4/ar01s04.html
, we need to send _NET_WM_MOVERESIZE_CANCEL when we get mouse release
event.
Task-number: QTBUG-91077
Change-Id: I01e74a01c87b381ee7cd6f20d51a1fa61c0e98fc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Amends 16f927a4f1.
At the time the original change was written, QStringTokenizer
had not been integrated, yet.
Change-Id: I83c31d816199bc48c4baea855d13cbf9eda9aaa2
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
PAGESETUPDLG's hDevMode reports the page size and orientation selection
of the user, so read that data to get accurate results.
Otherwise, the page size of a landscape page wouldn't match any known
page format, and we'd end up with a custom size that would not be valid
for the preview, breaking the preview UI's orientation state.
Reuse the helper from QPageSize to map Windows page size ID to our own
enum.
Fixes: QTBUG-93764
Pick-to: 6.2 6.1 5.15
Change-Id: Ib9a848619e3ba8780264ad76ed43c4fffae6b07f
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Since there is no header then the cells appear with no actual border so
it can look a bit strange without it. This ensures that the border is
at least shown when there is no header to represent it if the style hint
is turned on. This gives an option for those who want it to have it
turned on.
Fixes: QTBUG-85523
Change-Id: Ib94874bddddd31738fbcd41c6f77a2e0fa2ef443
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The iOS port creates one QIOSViewController per connected
screen. And each view controller listens for changes to
the application state. The problem is that we never
disconnect this connection again. So if a screen is removed, and
the corresponing view controller is deallocated, the
connection is still kept alive. This will cause crashes to
occur when the signal emits, since the slot will then be accessing
deleted memory.
Fixes: QTBUG-76948
Pick-to: 6.2 6.1 5.15
Change-Id: I758e51af9297cd62de193aae825f4475a2c7c3e5
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This reverts commit 03eb44394e.
Reason for revert: This breaks the dependecy update round in dev now. The revert can be reverted again after
1) Full dependency round is succeed in 'dev'
2) Android extras submodule has been removed from qt5.git#dev (7aa41d22fa485f212aebbef500ea91921c7bc38b)
3)qtmultimedia has been ported to use new api instead of this old one
4) Full dependency round with all above is succeed in 'dev'
Change-Id: I23241d2a90307074ecfc9573d2b58baba1874cfc
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Fixes build issue "no instance of overloaded function "qHash" matches
the argument list" on INTEGRITY
Pick-to: 6.2
Change-Id: Ia1273587840d55199846dc64d487d194f9a4d565
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Fix various C4244 warnings with the MSVC compiler for 64 bit
Proposed upstream fix:
https://github.com/mity/md4c/pull/162 for an upstream fix,
Pick-to: 6.1 6.2
Change-Id: I2ac1c17febb4fb269ac7244458f4cd90ce8b8e49
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Update the bindable property docs to explain how to deal with virtual
getters and setters.
Task-number: QTBUG-92994
Pick-to: 6.2
Change-Id: I6c29011817e83623414b39afee0f39ad4cc5c1c9
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The link, allegedly to the pcrepattern(3) man page, was in fact a link
to a .txt file giving an over-view of the pcre library, but not
describing the pattern syntax. Link, instead, to the actual HTML
version of the pcrepattern(3) man page.
Change-Id: I566fa5185b909bceb51dfe9f253c98f858f6a182
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Previously, it went direct to QTestResults::addFailure() without going
via the checking for expected failure. Add QTestResults::fail() to
take care of this checking, as for verify() and compare().
Tidied up the code implementing expected failure and QFAIL(), while I
was about it. Adjusted an existing test to verify that expecting a
QFAIL() works, by using QFAIL() instead of QVERIFY(false).
Remove the QVERIFY(false) whose comment brought this to my attention.
[ChangeLog][QtTestLib][QFAIL] QEXPECT_FAIL() now correctly anticipates
a subsequent QFAIL(). Previously QFAIL() counted as a fail regardless.
Change-Id: Icc28cf70e5ff3006363791ea03aa01f2f591eb71
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The tool used QCoreApplication::translate(), but did not attempt
to load a QTranslator. Use QStringLiteral() instead.
Pick-to: 6.2
Task-number: QTBUG-75870
Change-Id: Ib3c6b1893889a82b186a310c0c725dbf1a1885b3
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
There are multiple macros used to get/check and return with error
in case the requested object is not valid. These macros are defined
in multiple places and duplicated. This patch defines them in one place
and then they can be reused.
This macro expects a "char m_qtTag[]" variable to be defined in
the scope where the macro is used. That variable is used as a tag
for the error message printed when an error occur.
Another consecutive patch use the new macros over qtbase code.
Pick-to: 6.2
Change-Id: Ibb8558d1229cec6dad9ec9da6e2635ea54fd18d6
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
Move QT_END_NAMESPACE macro out of the #ifdef definition
Pick-to: 6.2 6.1 5.15
Change-Id: I26b4e263b5ae0acebf035dbfe8c7e287cd740190
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
It may change in the future.
Change-Id: If65bf690b12d4e6474557d7a48567941b18413bf
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Clazy warns about the fromUtf8() call with a constant argument, for
every use of the macro, so hide the stuff behind a compiler firewall.
Also fix the format injection error by using QLatin1String::arg()
instead of QString::arg() chaining.
Change-Id: I4bb4d4af56443540efc0c38c75819aa152a441fc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Also, a minor clean-up: isMatchingHostname() overload
was never used, deleted (and it could not be used safely,
since it requires the name to be normalized first).
The file (qtlsbackend.cpp) was re-shuffled, to have
backend on top of the classes which this backend
is factory for.
Pick-to: 6.2
Pick-to: 6.1
Fixes: QTBUG-91929
Change-Id: I435c69b167f57f7c3f76e34449c52f665dc6f7c2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It's no longer used today.
And while we're at it: delete or fix typos in some nearby comments
Change-Id: Ib52268eeb936e71d6c09aece2e0833b99309ef2d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
SETTINGS for max concurrect number of streams is 'one direction' - this
is how our peer conveys the possible number of streams _we_ can open,
not _them_. If they choose to have it unlimited - let it be so.
It's possible to send 0 as maximum number, also, it's possible to
reduce the maximum compared to initial at some point - then I have
to avoid integer overflows.
Pick-to: 6.2
Pick-to: 6.1
Pick-to: 5.15
Fixes: QTBUG-94470
Change-Id: Ia02247acbaedd70998a4cab02082ba10f45cf78c
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Previously they all returned the runtime versions and one string
function did not include the backend's name.
The NTDDI_VERSION macro is what we use to base certain
feature-availability on during compilation so it makes the most sense to
use for the build-string.
Pick-to: 6.2
Change-Id: I96b025a5a05c0bbb4db3d5ee68656e0df5f4eb07
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
QByteArray creates copies of data, but we usually don't need the copy
and a view, for comparison or fetching substrings, is enough. So instead
we use QBAView and QLatin1String (when we need to go through
QStringTokenizer).
Change-Id: I12e0bd8777fc63f676b9371abfd345fab1046c44
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
...if changed after the widget is shown.
Just documents the current state of things.
Task-number: QTBUG-60822
Task-number: QTBUG-59126
Pick-to: 6.2 6.1
Change-Id: If8281dce4457707a1673aca7a50744d8b231b030
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Use integral consts instead of enums for algorithm constants;
handle QChar::Decomposition as such, rather than as an int;
pass QChar pointers to cut down on reinterpret_cast<>s;
use char32_t instead of uint for UCS4.
Change-Id: Ia535128602065392a1b46fbb0a81572026be5d00
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
