Two QCOMPARE calls aren't worth the extra indirection.
Change-Id: If3b54d303c28582c7df29a3f1c4dc1a2c2a974f4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
About the requirement of wrapping unitests in "#ifdef
QT_BUILD_INTERNAL".
Stating the obvious (which wasn't obvious to me until Thiago pointed it
out in code review, so).
Change-Id: If8b3dda43a7034b8304d2b93c0fbedbdbdb184b6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The 3-arguments overload of connect() is error-prone / easy to misuse:
* it's easy to e.g. connect to a lambda, and capture local state in the
lambda. By not passing a receiver/context, the connection won't get
disconnected if the local state gets destroyed (effectively, it
creates a "dangling connection");
* in a multithread scenario, one may not realize that the connection is
forced to be direct. If the signal is emitted in another thread than
the one establishing the connection¹, then the functor will be invoked
in that other thread. (Not that "the thread establishing the
connection" has ever mattered, but again, this API is error-prone.)
Add a macro that allows users to disable the overload in their project.
I'm not going for deprecation because there's simply too much code
around that uses it.
[ChangeLog][QtCore][QObject] Added the QT_NO_CONTEXTLESS_CONNECT macro.
Defining the macro before including any Qt header will disable
the overload of QObject::connect that does not take a receiver/context
argument.
Change-Id: I86af1029c1a211ea365f417aae9038d3fcacadfd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The 3-arg connect is error-prone and makes the lifetime of the
connection unclear.
Change-Id: I4f2b54bc086e8f4723a0357d983e3df2f85135ac
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Why do we need this feature: to give user the possibility to explore
different interesting graphics features (currently only compatible
with D3D with the new FLIP model).
Why do we need to modify QPA directly: touch this flag after the
window has been created has no effect. It can only be used when we
call CreateWindow(), so we can't add this flag through SetWindowLong().
However, Qt doesn't provide any public or private interface to
control how Qt call CreateWindow(), and providing such interface
is also dangerous. Using environment variable to control this behavior
is the simplest solution and is commonly used inside Qt code base.
Change-Id: I12440ed498d97cc17640e6c7498e42770b813737
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
When a table view adds its first row, QHeaderView::initializeSections()
is called. It initializes the vertical header view with the number of
added sections. Subsequently QHeaderView::sectionsInserted() is called
with the same amount of newly added rows/sections.
That leads to the initial amount of sections being 2x the number of
rows added in the first go. In other words, the table view will display
at least one row more than the underlying table model has.
This patch adds an OR condition to the early return check at the
beginning of QHeaderView::sectionsInserted(). The method returns early
if the number of sections equals the number of respective sections
(rows in this case) in the model.
An autotest is added in tst_QTableView::rowsInVerticalHeader().
Fixes: QTBUG-114225
Pick-to: 6.6 6.5
Change-Id: I895444f025591981965562e54e2335391db52357
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
33c88f86b5 added some logic to QAPM in
order to have it automatically emit headerDataChanged when rows/columns
were added or removed in the model. This was done as a stopgap measure
to prevent QAPM from asking for illegal indices in order to implement
automatic remapping of the section headings (since there's no
mapSectionToSource).
The commit seems to have introduced a regression in QHeaderView, which
isn't prepared to receive headerDataChanged while a row/column count
change is in progress. When receiving headerDataChanged, QHeaderView
will try to read the row/column count and will store it internally.
When it will then receive the signals for insertion/removal of
rows/columns, it will interpret it as a modification of the previously
stored value -- even if the value it stored was already correct.
Fix this by avoiding to have two signals in flight at the same time;
emit headerDataChanged as a queued invocation.
Task-number: QTBUG-114225
Change-Id: I521465a852b8c7135f22f730ead41dca760ba428
Pick-to: 6.5 6.6
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The CMakeUserPresets.json file can be used to simplify configuring Qt,
particularly with tools such as Visual Studio and Visual Studio Code.
As opposed to the CMakePresets.json, the CMakeUserPresets.json should
only contain user specific configurations, and should never be checked
into source code management system.
This file is already ignored in the top level Qt super-project, but to
facilitate working with each individual submodule, we should also have
this .gitignore in each submodule.
Pick-to: 6.5 6.6
Change-Id: I383417c7fe9d803aeb0385ba83e8c9cee6181602
Reviewed-by: Miguel Costa <miguel.costa@qt.io>
In the iOS theme, we determine the color scheme based on the the last
UIWindow of the application, but listen to trait changes in the
QUIWindow class. However, the last window of the application is not
always a QUIWindow. Sometimes it can be a temporary UIWindow created
by the system for transitioning or other effects. These kind of windows
do not always follow the appearance of the app and the main window
(QUIWindow), so we were sometimes ending up with the wrong color scheme being reported.
This was happening when the app was put into background for example,
which causes the traitCollectionDidChange method to be called and query
the userInterfaceStyle of the last window to determine if the color scheme was changed. The queried window would sometimes end up being of type UITextEffectsWindow, etc. and report the wrong appearance.
To fix, always make sure to get the appearance from a QUIWindow.
Fixes: QTBUG-114571
Fixes: QTBUG-113169
Fixes: QTBUG-114191
Pick-to: 6.5 6.6 6.5.2
Change-Id: Ic0b29c02c8e8100996d5cd31b37e6a5b839f5fb1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
INTEGRITY has a pre-P1115 implementation of std::erase/erase_if that
returns void instead of the number of erased elements, so make q20's
implementation more specialized, so the compiler will pick it over
INTEGRITY's (Marc's idea from the code review).
Change-Id: I88d025a3f90cdd65f5bb73beb8a39e32ccf12d9b
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
... like QUIP-0019 suggests.
The main problem here is finding these classes. We don't have markup
for RAII classes, so I had to find them by name. This patch is based
on the output of
git grep -we Q[A-Z0-9a-z_]+er
extracting the matches and piping them through sort -u, then removing
a lot of suffixes like Manager and Handler, then visually inspecting
the remaining list.
Task-number: QTBUG-104164
Pick-to: 6.6
Change-Id: I59b18d8d0a0237fcc11047857adc39b984ad7fcb
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Wrappers around P1301 [[nodiscard("reason")]].
[ChangeLog][QtCore][Q_NODISCARD_X/Q_NODISCARD_CTOR_X] Added as
wrappers around C++20 [[nodiscard("reason")]].
Task-number: QTBUG-114767
Change-Id: Ie566d9c9d500ef632c7e243af97081f83506a752
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
If we are already disconnected we end up printing warnings about how it's
illegal to call waitForBytesWritten on an unconnected socket
Change-Id: I8c864d105d5372edfee84affb362cca3021b8ea0
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Only when available at build time (dxcapi.h) and at run time
(dxcompiler.dll, ideally with dxil.dll).
The catch is that the latter will not be true in a typical Windows
system. Unlike the legacy d3dcompiler_47.dll the dxc stuff is just
not there. It is unclear what we can do about it. In the meantime
one needs to go to https://github.com/microsoft/DirectXShaderCompiler/releases
and get the DLLs.
Fixes: QTBUG-114773
Change-Id: I6e68fdd1e47505187036b47d6f3e7fe9cc4ee8dc
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Only for dev and 6.6, includes D3D12.
6.5 has its own dedicated version of the patch.
Fixes: QTBUG-114775
Task-number: QTBUG-114115
Pick-to: 6.6
Change-Id: I36c96e046ba611b228fd5c320e5780ca4d180165
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
This relies on qsb being able to invoke dxc instead of fxc when the
request HLSL (shader model) version is 6.1. (6.1 is required for
SV_ViewID) This currently works only when conditioning offline with
qsb (or via CMake), because qsb can easily invoke dxc instead of
fxc. When shipping HLSL inside the .qsb package (so when -c is not
specified or running the external tool fails), this won't work since
the D3D12 backend still uses D3DCompile(), not IDxcCompiler. Support
for that will be investigated separately.
We also need to bump to ID3D12Device2 and ID3D12GraphicsCommandList1.
With Windows 10 version 1703 being quite old now, this should not be a
problem at run time.
There are however issues at build time, namely that MinGW and
MinGW/LLVM and similar seems to have ancient Windows SDK headers
according to the CI test runs. None of the MSVC configurations have
this in the CI, they have reasonable versions of d3d12.h and similar.
Therefore, one important aspect of this change is that the D3D12
backend of QRhi will only be available from now on when the SDK
headers are new enough (meaning ID3D12Device2 is declared, which is a
several years old type now). Otherwise, QRhi::create() will simply
fail when asking for D3D12 with a helpful warning message about the Qt
build being crippled.
Implementation-wise, there are surprises in store as well:
The way the PSO is created needs to be revamped to follow the
extensible approach that uses a pipeline state stream
description. Both the graphics and compute pipeline creation is
changed to use CreatePipelineState() and the associated
machinery. This is only really essential for graphics pipelines since
we know have to include data for view instancing (multiview). For
compute the result is the same as before.
Additionally, the view count must now be baked into the
QRhiGraphicsPipeline. This means that applications must call
setMultiViewCount() with the same value (typically 2) *both* on the
render target's color attachment and on the pipeline. Backends that do
not care about the pipeline's view count (GL, Vulkan) will of course
ignore it, but if it's not set correctly D3D12 will fail. The manual
test is updated accordingly.
Fixes: QTBUG-114772
Change-Id: I93db7313377e711c2faeb956815899b12132d23b
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Under some circumstances, MSVC seems to complain about SlotArgumentCount
being unused
qobject.h(210): warning C4189: 'SlotArgumentCount': local variable is
initialized but not referenced
note: see reference to function template instantiation
'QMetaObject::Connection QObject::connect<void(__cdecl QAction::* )(bool),
main::<lambda_1>>(const QAction *,Func1,
const QtPrivate::ContextTypeForFunctor<main::<lambda_1>,void>::ContextType *,
Func2 &&,Qt::ConnectionType)' being compiled
This is nonsense, as SlotArgumentCount is used in the next line, to
construct the list of signal arguments, but the workaround to declare
the variable as [[maybe_unused]] is trivial.
Add a connect statement to the test case that creates such a connection.
This does not produce any warning with or without the attribute (and if
it did, the build would fail for CI configuratinos setting -Werror).
Pick-to: 6.6
Fixes: QTBUG-114781
Change-Id: I4ee6f7d57c2836ef3dd9741d037d48181af2cdec
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Adding some Qt Design Studio macros for global
qtdoc use. This would ensure flexibility for
the documentation writing.
Pick-to: 5.15 6.5 6.6
Task-number: QDS-10142
Change-Id: Id61a68d124aad1b8c8f9e17358fb5990efbab5de
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Previously, Qt would always ignore user's custom QSurfaceFormat
settings and this behavior makes user have no way to control
the preferred OpenGL version when running on WASM. And after reading
the wasm platform plugin code, I don't see any reason why we should
limit ourself to the default OpenGL version. And I've tested this
patch locally, Qt still work normally if I set a newer OpenGL version.
Pick-to: 6.6 6.5
Change-Id: I0cfb831d6a722fe61cc85808a6d9e3098c73d82e
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The concatenated byte array is already the "size" we want.
Drive-by change: use QByteArray::sliced()
Change-Id: Id0afb45ae1daf08bd125230eef0734770c645e1a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change Generator::generateSignal() to take by const FunctionDef*, so
that it can be called with the return of QList::at().
Change-Id: I5ffb0726a5ded6561e0000a2bea1973ada675152
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
No need to copy the 3 QLists to iterate over them.
Change-Id: Id0fc7d39012bdaa78e51b1153565df77c7fb889a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
By handling the special case before entering the loop, then it can
become a range-for, which fixes a narrowing conversion warning, and it
becomes more readable.
Change-Id: I6ce0181c95eae01a4f2bb7cd12fb5cbeba378586
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Yes, the code now uses two loops, but it's slightly better than
erasing-during-iteration; the alternative is using e.g. a while loop and
advancing an iterator manually with operator++() (in two separate
locations, since there would be a `continue` statement) or with the
return value of QList::erase (in one location).
Change-Id: I119d0e61bc06396f2158ecf9f4ae84a76d9bce7b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Instead of changing the "index" member then restoring it, add a
symbolAt() method to get the Symbol in question, and pass it to
new warning() overload.
Change-Id: Ie84a6cf4d837f4ed694f617100e9556c2fc2eea3
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Setting color scheme before handling theme change provides incorrect
palette color when user switches from light to dark or dark to light.
This is visible when using Fusion style (or other style that supports
dark mode) in Windows. The change has been made as part of patchset
787038bb1d.
It also has to be noted that handling palette changes to make further changes to the palette (or the style sheet), is less likely than
Handling the colorScheme change signal and in this sense, this patch set
can also be considered as an improvement.
This patchset reverts that change and updates color scheme after palette change in the application.
[ChangeLog][QtGui][ColorScheme] Update colorScheme property after
palette change.
Fixes: QTBUG-112653
Pick-to: 6.5 6.6
Change-Id: I71bc413c56663fefdf9fe5871bbb19b7e6c3d9ff
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Make it so that what we query with regards to 1.1, 1.2, and 1.3 features
are stored for later use. This will be relevant for e.g. multiview where
the multiview field will need to be checked when deciding if the feature
is supported at run time.
All this is only really compatible with Vulkan 1.2 and newer. Vulkan 1.1
does not have the 1.2 approach, i.e. there is no
VkPhysicalDeviceVulkan11Features
in Vulkan 1.1 (!). That is a struct added in Vulkan 1.2. In 1.1 one had
the feature (extension) specific structs, such as
VkPhysicalDeviceMultiviewFeatures
in case of multiview. That we do not bother with at the moment.
Then again that's nothing new. The existing code to enable all features
with a few exceptions, that's already tied to the 1.2+ way of working
with physical device features, and not quite compatible with a pure
1.1 (not 1.0, not 1.2+) implementation (which should be hopefully rare
out there).
Pick-to: 6.6
Change-Id: I661f2634651d28edd9b5feec66a423220920f894
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
It has no purpose (like Alt+Enter is not functional anyway when we
created the swapchain for composition), and with D3D12 there is a
warning printed (with the debug layer enabled?) about this. So move
the call to the appropriate branch.
Pick-to: 6.6
Change-Id: I266ae6835bcc49b3ba8d84e5d08ab9115c6401e0
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
It's a named constructor of a smart pointer class. QUIP-0019 says
constructors of such classes should be marked as [[noexcept]]. It
doesn't (yet) say anything about _named_ constructors, but it makes
sense to include them, too.
Pick-to: 6.6 6.5
Task-number: QTBUG-104164
Change-Id: Ia4b43e4f819ce45d71274019c919fd98cc97878b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The lock() function, added for std::weak_ptr compatibility, sounds
like QMutex::lock(), but is, in fact, a const function. QUIP-0019 says
such functions must be marked [[nodiscard]]. For symmetry, also mark
toStrongRef() and toWeakRef() as [[nodiscard]].
Pick-to: 6.6 6.5
Change-Id: Ifb6e447d2cd96fedd9a78decdfac6bc57c1d282a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The following private APIs are either RAII or smart pointer classes:
- QAutoPointer
- QBoolBlocker
- QFdContainer
QUIP-0019 says to mark RAII and smart pointer class ctors
[[nodiscard]], so do that.
Pick-to: 6.6
Task-number: QTBUG-104164
Change-Id: Ibc77e6603fadf18ea28428a49635f46a5680b777
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
They both check __has_cpp_attribute(nodiscard), so keep them together.
Move the fall-back (empty) definition to the block that does the same
for all other such macros.
Mention that both P1771 ([[nodiscard]] for ctors) and P1301
([[nodiscard("reason")]]) use the same numerical value.
Amends 959800f6de.
Pick-to: 6.6
Change-Id: I0ef913b6076ffa4058220b542303591de6fefde7
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
It should be possible to build a test in any configuration
by building Qt in that configuration, and then building
the test with qt-standalone-test.
Not all Qt configurations will be able to run all tests,
(due to exec() calls and similar) but that's OK - some
tests don't have exec() calls, and we want to be able
to run tests for a given configuration to figure out
how well it works.
On CI we want to use batching and asyncify, so it makes
sense to tie usage of asyncify to batching.
Pick-to: 6.6
Change-Id: I05553d250a45c1831f43dc71a43ef02d01d70535
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
If the user is asking us to ignore it, don't set to the default
behavior.
Change-Id: Ib5ce7a497e034ebabb2cfffd17628562f745358d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
... into a new local class called QChildProcess. This groups all the
information that the child process will need between the fork()/vfork()
call and the eventual execve(). That currently includes:
- the argv array, including resolving the program name to a path
- the envp array, possibly a null
- the working directory file descriptor
- the disabled thread cancellation state
We also move the fork() and vfork() calls to inside of this class,
eliminating the the nested lambda was passed to vforkfd(). This
duplicates the trick of calling a lambda in the child side of vfork()
now for the non-file descriptor version too.
None of this should have a side effect for the application. You may be
able to tell apart only in system-call tracing tools like strace(1) or
truss(1).
Change-Id: Ib5ce7a497e034ebabb2cfffd176284edfdd71b32
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
And take the opportunity to clarify what the QtVforkSafe namespace is
doing. Amends commit e71c226d6f.
Pick-to: 6.6
Change-Id: I443cf0c8a76243eead33fffd1767f3fa390a7cdd
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Found in API review.
Amends 959800f6de.
Pick-to: 6.6
Change-Id: I00877ce7030c638765b495089899c022deb31a27
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
QFutureSynchronizer is a RAII class. QUIP-0019 says that RAII class
ctors should be marked as [[nodiscard]].
Pick-to: 6.6
Task-number: QTBUG-104164
Change-Id: I0b6710f2b9a14d67f64150f240f819b8336e0929
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
When setFuture() was handed an element of m_futures, it would hold the
reference to past the clear(), which invalidates said reference.
Fix by taking the future by value instead of by cref.
While append() is not affected, as QList::append() already guards
against aliasing, do the same change there, both for consistency as
well as to optimize the common case of passing rvalues. It also means
we can use the rvalue overload of QList::append(), skipping the alias
analysis in the lvalue QList::append().
[ChangeLog][QtConcurrent][QFutureSynchronizer] Fixed a crash in
setFuture() if the argument was already a member of
QFutureSynchronizer::futures().
Pick-to: 6.6 6.5 6.2
Change-Id: Ic0b212b9f265a746df9a6beb6272a5415d131442
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
