The previous commit, b0e4d53b63, missed
this one. Same rationale as back then.
Pick-to: 6.4 6.3
Change-Id: Ibad4c130e0d61c64808275fa7b97b58ebd479acc
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The old code assumed that a QByteArray's data() is always
NUL-terminated. Due to the conflation of owners and non-owners in
QByteArray (but also in case we ever get efficient substringing), this
is not always the case, e.g. QByteArray::fromRawData() does not ensure
NUL-termination.
From QString::utf16(), we learn that the condition to check for is
QArrayData::isMutable(). After working around the fact that
QByteArray::data_ptr() doesn't exist for const QBAs and that empty
QBAs always refer to QByteArray::empty_, which is !isMutable(), we can
detect this situation and re-allocate without introducing new API.
This is the fix for Qt ≤ 6.4. For Qt 6.5, we'll port the function to
QByteArrayView.
Pick-to: 6.4 6.3 6.2 5.15
Fixes: QTBUG-105302
Change-Id: I3416535ab09d601e0e87b2767f2c024ba1217e64
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Processing shortcut events may result in the window being deleted, so
we need to check if m_platformWindow is still valid before continuing
with the key press event.
Pick-to: 6.4 6.3 6.2 5.15
Fixes: QTBUG-105160
Change-Id: I9cd362873b19c078a4fced3ac3c815d70bfc7fbe
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Those operators return a value, not a reference.
Fixes: QTBUG-104940
Pick-to: 5.15 6.2 6.3 6.4
Change-Id: I117892f12d20c6bf32a12f37c1bdfec1817614c6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Issue a glFlush in endOffscreenFrame. This matches endFrame which
flushes either implicitly (swapBuffers) or explicitly with SkipPresent
(glFlush). This will then benefit producer-consumer setups where a
context renders into a texture using begin/endOffscreenFrame and then
the texture is consumed in another context.
In addition, make finish() issue a glFinish().
Pick-to: 6.4
Change-Id: I0a3115255ad2ac82b730e26d1ca7e88377c5a28c
Reviewed-by: Piotr Srebrny <piotr.srebrny@qt.io>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Explicitly running the install step would fail in a non-prefix build.
Do it conditionally on the no_prefix feature.
Pick-to: 6.4
Change-Id: I78cd63f51c499a0df451b08290c6dfc84e52666c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
qt_copy_framework_headers now can accept all the headers in one call.
This is useful for upcoming changes when it will accept generator
expressions as the input instead of actual files.
Change-Id: I110b6d9e6de976b2a7581902e051e38571716c5f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The call to displayName is not guarded by the same ifdef.
Pick-to: 6.2 6.3 6.4
Change-Id: I169777130ec316a2d2f837621280acb061072501
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
We forwarded the compiler path to the EP but not the flags that might
have been set via the CXX environment variable.
Make sure to also forward the flags.
Pick-to: 6.2 6.3 6.4
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I0fbf9b595f7885014b1f09d158db52e56a3d5243
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
When building qtsvg examples as external projects on Windows
with Ninja Multi-Config in a prefix build on the CI, the build would
fail with an error message like:
ninja: error:
'C:/Users/qt/work/qt/qtsvg/lib/Qt6SvgWidgets.lib', needed by
'RelWithDebInfo/svgviewer.exe', missing and no known rule to make it
This can be reproduced locally on Windows if one calls
'ninja svgviewer' instead of just 'ninja'. I wasn't able to reproduce
it on macOS, although I have seen some peculiarities in the
dependencies there as well.
External project examples depend on the ${repo_name}_src custom
target to ensure all Qt modules are built, so one would expect that
dependency to be sufficient.
While trying to figure out what's going wrong, I noticed that running
'ninja -t query qtsvg_src:Debug' showed dependencies on Release
libraries, which should not happen. The :Release target looked fine
though.
I'm still not quite sure why the Release libraries are not built
on the first ninja run, despite the example having a proper dependency
on qtsvg:Release.
Running 'ninja svgviewer' a few more times ends up succeeding at one
point, because the SvgWidgets Release library does get built in
parallel with the failing example, and the next rebuild would
succeed.
While trying to fix the :Debug target to have proper dependencies, I
noticed that we add dependencies to the ${repo_name}_src custom target
via the DEPENDS option of add_custom_target(). That is incorrect,
that option should only be used for file level dependencies.
For target dependencies, add_dependencies should be used.
Doing that fixed both the :Debug dependencies as well as the Windows
issue, which is good enough for me.
Amends 08f46bb400
Pick-to: 6.2 6.3 6.4
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I1888681e2e9362d3237acbdacc83222d6a60b48e
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Always make sure to initialize the OpenGL functions. Instead of relying
on the shaderprogram initialization, which is bound to the current
context, check for the d_ptr and initialize when not already done.
With this fix QEglFSCursor::draw works regardless of which context is
current and checking for that is not needed anymore in paintOnScreen.
This is important as the basic render loop only uses one context for
painting on all screens, while the threaded render loop uses multiple
contexts.
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: I4ac2f5184c2fce27421e92efe1b7f635c71c0e92
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
All versions down to Qt 6.2 require macOS 10.14 or iOS 13.
Pick-to: 6.2 6.3 6.4
Change-Id: I5048921ea5a149346a0fa84228227d9156004675
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
All versions down to 6.2 require at least Xcode 12, which ships with
the macOS 11 SDK, and iOS 14 SDK.
Pick-to: 6.4 6.3 6.2
Change-Id: I128321ec9e97b670b7c027f1233978e1b8856f88
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
As a drive-by, add a link back to Q_ASSUME() in Q_LIKELY() docs.
Change-Id: I4a46e281d0fbf55c11001f15667fcc4faa3b0c5b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The forward header for QFunctionPointer was being generated by accident,
apparently syncqt is confused because of some of the preceding lines. If
the lines are rearranged or removed, the header won't be generated. Not
sure if there's much value in generating a header for it, but at least
one of Qt sources (qeglfsemulatorintegration.h) is using it in an
include statment, and there's a chance it's used in the user code as
well.
Change-Id: Iced505881ddb07e7a8336fcdfb7d3e5397c6466c
Pick-to: 6.4 6.3 6.2 5.15
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For now qassert.h is included in the middle of qglobal.h, since some of
the code below needs it, but this will be cleaned up when that code is
moved in its own header.
Task-number: QTBUG-99313
Change-Id: I2cdfed44f5c8772c1dad4797cf8edc6cb4c964b4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
qcontainerfwd.h was relying on the forward declaration of QString in
qglobal.h, so add the missing forward declaration there.
Task-number: QTBUG-99313
Change-Id: Id3ecaed5ce3b64dabb8454647a43d1520d30e713
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The relational operators <, >, <=, >= do not form a total order for
pointers. In particular, they are only defined for pointer pairs that
point into the same array (incl. one past the array's last element).
Other uses are undefined behavior.
The iterators the class works on are user-supplied, so we cannot
assume that they are pointing into the same array. In fact, we have a
check in setPosition() that tries to catch such misuses, but similar
checks are absent from the ctors, e.g.
In addition, the implementation itself is checking for next-but-one
and prev-but-one in an unsafe way.
std::less can be used to provide a total order, so use that
everywhere.
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: I32fb0ef9f768d9336ae12cc0542ca18d1bf23adf
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
QVarLengthArray checks for is_nothrow_move_constructible_v, though only
uses that information for its own noexceptness.
Pick-to: 6.4
Change-Id: I03c81e4da75fbe287d491843716d26e1acac8310
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Says Clang 10:
tst_qfocusframe.cpp:73:28: warning: using the result of an assignment as a condition without parentheses [-Wparentheses]
QTRY_VERIFY(focusFrame = window.findChild<QFocusFrame *>());
~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
tst_qfocusframe.cpp:73:28: note: place parentheses around the assignment to silence this warning
QTRY_VERIFY(focusFrame = window.findChild<QFocusFrame *>());
^
(
tst_qfocusframe.cpp:73:28: note: use '==' to turn this assignment into an equality comparison
QTRY_VERIFY(focusFrame = window.findChild<QFocusFrame *>());
^
==
Amends f1812aad89.
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: I3920ab0da725b76fb6c19bbc7cde7920f351af4a
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Move most string handling code out of the environmentMutex critical
sections to increase parallelism (Amdahl's Law).
I drew the line at temporarily dropping the mutex to allocate memory
for the return QByteArrays, as that would have meant to loop over
obtaining the size, allocating it, and then copying the data which
would have overly complicated the code.
Pick-to: 6.4
Change-Id: I980cbf7fda76fc8057f84b2539b4a299e06cae82
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
I don't expect environments to allow values or names > 2 Gi
characters, so this is just for consistency (int is a code smell these
days).
As a drive-by, replace
QString buffer;
buffer.resize(n);
with
QString buffer(n, Qt::Uninitialized);
Task-number: QTBUG-103527
Pick-to: 6.4 6.3 6.2
Change-Id: I0e41a6e7e9c44ff1ec22377329735538d5f95181
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The std::boyer_moore_searcher is buggy for older verions of Microsoft's
STL, and missing in AppleClang's libc++ with an inefficient fall back.
Fixes: QTBUG-100236
Change-Id: Ic3cc916946546d2ef78456cd15e1425d957b989d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Added a parse option that can be passed to setContent(), to specify that
spacing-only text nodes must be preserved.
[ChangeLog][QtXml][QDomDocument] Spacing-only text nodes can now
be preserved by passing the ParseOption::PreserveSpacingOnlyNodes option
to setContent().
Fixes: QTBUG-104130
Fixes: QTBUG-89690
Task-number: QTBUG-90003
Change-Id: Id43730ce5b79a856c4b434d1f1d4dd7c49c25f31
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This avoids having to rely on moc precalculating everything and getting
its sums right, as the main integer table only has a string index
(unlike my original 5.0 plan which would have stored the offset).
For example, for:
struct Object : QObject { Q_OBJECT signals: void changed(const QVariant &v); }
moc now generates:
struct qt_meta_stringdata_Object_t {};
static constexpr auto qt_meta_stringdata_Object = QtMocHelpers::stringData(
"Object",
"foobar",
"",
"v"
);
Notes on the implementation:
* the old code is retained because we need moc 6.5 to generate code
compatible with QtCore 6.2-6.4. It's marked for removal in Qt 6.9.
* the struct qt_meta_stringdata_%s_t remains because we need a
TU-specific type for QtPrivate::is_complete (via
qt_incomplete_metaTypeArray). This can be cleaned up.
* after this change, GDB complains while loading QtCore:
warning: internal error: string "StringData<long sequence of numbers>" failed to be canonicalized
but debugging does not appear to be impacted. It's just annoying
because it shows up when QtTest detects a crash too.
Change-Id: Id0fb9ab0089845ee8843fffd16f9d5493e9bd708
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Converting from QImage::Format_ARGB32 to QRhiTexture::RGBA8 requires
texture swizzling also on big endian. But unlike on little endian it
is not a red/blue swap that is needed, but a rather rotation of the
alpha channel from the first component to the last.
Add a new swizzling mode to the backingstorecompose fragment shader,
and rename the uniform to reflect that it no longer covers only
red/blue swapping.
Pick-to: 6.4
Change-Id: I001d275abdc88faaadea16e396ebe032b34e83f0
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Using QTime(), which is null and invalid, as the time field of a
QDateTime is supported, but is ill-advised. Use the start of the day
instead.
Change-Id: If30db046218926f7634bbcfcf35cd000d7f6535f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since 6.3 these use Qt::UTC as time-spec but I neglected to take that
into account in QDateTimeEditPrivate::init()'s construction of a
QDateTime from the QDate or QTime. This amends
commit c00ee2f310.
Fixes: QTBUG-105322
Pick-to: 6.3 6.4
Change-Id: I11dec9808a54cf7da401b1734a9a2812f5fd2e63
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change to match how QDateTimeEdit()'s overloads taking a QDate or
QTime work, substituting a default value in place of an invalid one.
This fixes one surprising anomaly in a recently-extended test, so that
it now only fails the way I expected.
Task-number: QTBUG-105322
Change-Id: Ied4da6160b7efe70990f956798fb826b5b36d8bb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The constructor_qdate() and constructor_qtime() tests only tested
QDateTimeEdit with a QDate or QTime. Extend them to also test
QDateEdit and QTimeEdit constructors, respectively. This revealed one
surprise; the QDateEdit constructor doesn't replace an invalid QDate
with the usual start-date, as the QDateTimeEdit does. It also serves
to reproduce a bug reported in Qt 6.3, see Task-number. These are
all marked XFail for now.
Task-number: QTBUG-105322
Change-Id: Ifafb40a9b78d9314b74ca9a1710d362b9a3cb18d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It makes no sense to pass, as parameters, values that can't vary
between test data rows, so eliminate m{in,ax}imum{Dat,Tim}e
columns. There were no parameters used to control how those would be
set, so they were always going to be the type's defaults.
The displayDateTime was only needed for the invalid test, in which its
value is known and fixed; for the normal test it was necessarily
implied by the parameter used to initialize the QDateTimeEdit. While
the QDate and QTime tests do have to supplement that construction
information, the other part is again known and fixed. We can check the
data-tag against "invalid" to determine which known and fixed data to
use, saving the need for a data table column.
Change-Id: I3754ba1a6a127a4a872a7f4a3e7edad9a5ff0ec0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QVulkanWindow has recently been updated both in 5.15 and 6.x to start
enabling at least the 1.0 core features, because modern validation
layers are likely to complain if a feature is used without the
corresponding flag enabled upon device creation, even if the driver does
not actually care.
There is a catch here however, namely that some features may be true
opt-in flags, e.g. robustBufferAccess, and when enabled, they may incur
a performance penalty. So we will keep that one feature disabled even
when it is reported as supported.
It is unfortunate that VkPhysicalDeviceFeatures mixes together flags
that are most likely used only to query if some feature is supported by
the implementation while not serving as a real toggle (because opting
in/out is meaningless for the implementations in practice), and flags
that have significant effects when the feature is enabled, for example
when it comes to performance.
As QVulkanWindow only cares about 1.0, and 1.1+ features are to be
handled by the application via the features-modifier callback, we can
get away by just disabling robustBufferAccess and passing in everything
else supported as-is for vkCreateDevice.
Task-number: QTBUG-105158
Pick-to: 6.4
Change-Id: I963402ab50f6e5d3fa6824680f69cff8568b669a
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Apparently, we still support these architecture versions, and there's
no way to detect ARMv6k-or-greater specifically, so exclude yield for
ARM < ARMv7.
Amends 877c158c59.
Fixes: QTBUG-104316
Pick-to: 6.4 6.3
Change-Id: I51a2f0f8e0993dba41e47bb6110473ac8e7cd32a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
openssl3 uses uint64_t for the options argument in SSL_CTX_set_options,
older ones used long.
sizeof(long) is not the same on any platform as sizeof(uint64_t)
Fixes: QTBUG-105041
Change-Id: If148ffd883f50b58bc284c6f2609337d80fb5c58
Pick-to: 5.15 6.2 6.3 6.4
Reviewed-by: Dmitry Shachnev <mitya57@gmail.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
VkPhysicalDeviceVulkan11Features and co. need to be considered
separately, for now we just sync the enabling of 1.0 core
features between QVulkanWindow and QRhi, both in 5.15 and 6.x.
For QRhi in Qt 6 this will need to be amended separately once
the myriads of 1.1/1.2/1.3 features are investigated.
Like everywhere else, robustBufferAccess is disabled. We do not
want features that likely affect performance. To be checked
later on if adding some sort of opt-in mechanism for this is
sensible or not.
Task-number: QTBUG-105158
Pick-to: 6.4
Change-Id: Ia3d8c1e6bb8be8643e80178954dca0aa8b92d3c0
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The output was only printed if the request was no longer available
queued, meaning that it had been removed before the socket had finished
its connection attempt. That means the result of the attempt is not of
much interest to the user so we should not print it out as a warning.
The reason for why the request was removed from the queue would be the
interesting bit, but it's not covered here.
Task-number: QTBUG-85248
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: Iac483b8bb600e1577fe88c3699e46d50615bfccb
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
It's the same implementation. This also inlines the actual comparison,
to allow the compiler to implement the inline memcmp, if it so wishes.
operator< could be changed too, but QByteArrayView's makes an out-of-
line call to QtPrivate::compareMemory, whereas QLatin1StringView's calls
memcmp() directly, which allows the compiler to optimize.
Change-Id: I89c4eb48af38408daa7cfffd16fde9f2b0a8590b
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Instead of having that function load those from memory. This allows us
to pass constant expressions in QVariant::Private s constructor
Change-Id: I3859764fed084846bcb0fffd17045ddd62553710
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This means we can't do a tail-call from customConstruct when
PrivateShared is in use. But the case without that is still a tail-call.
Change-Id: I3859764fed084846bcb0fffd17045d144181ea84
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Even though it's calling a noexcept(false) constructor, we can declare
when it it won't throw and allow the caller to suppress its own
exception handling.
This necessitated splitting the Q_DECLARE_SHARED into its components
because fromValue<QVariant> uses QTypeInfo<QVariant>::isRelocatable.
Change-Id: I3859764fed084846bcb0fffd1704503aa4d3e535
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Group them by noexceptness and then organize each group logically. We
also don't need to #ifdef the constructors for the unavailable classes,
as they are forward-declared.
Change-Id: I6f936da6f6e84d649f70fffd17060903c78edf0f
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
