CTFontDescriptorCreateMatchingFontDescriptors has been observed to
return nullptr, so we need to handle that explicitly.
Fixes: QTBUG-113698
Pick-to: 6.5 6.6 6.2
Change-Id: Ic9fa574c14068fcae98fe8e6ceddd8a4f7008210
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
- Use unique_ptr instead of manual memory management
- Improve consistenty in variable name with the simpletreemodel
childrenNumber -> row, m_ prefix for member variables
Change-Id: Iface30c2224c2b1db7c623a9e6fcbb449c556f3e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Since qt_noop() is supposed to be a no-op, it should not affect
constexpr'ness and noexcept'ness of functions and expressions it's
(indirectly) used in.
That requires that it be constexpr and noexcept itself. Add the
keywords, but guard against use from C. We can't use our Q_ macros
(which would enable noexcept for C, too, on some compilers, because
qcompilerdetection.h depends on qtnoop.h, and we don't want the
circular dependency.
Pick-to: 6.6 6.5
Change-Id: Ie5441c423b7942a6c956345126fc7aec99907d25
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A class-level [[nodiscard]] used to be the only way to get a waring
for code such as
QMutexLocker(&mutex);
with original C++17 means. This was because a few of our compilers
would warn about the presence of [[nodiscard]] on ctors, which is
really the semantics we want: we don't want to prevent users from
passing QMutexLocker out of functions and users of those functions
from ignoring the return value, if they so choose. That should be the
choice of the author of the function returning such types, not ours.
So QUIP-0019 makes class-level [[nodiscard]] conditional on proper
rationale in the user docs (or the commit message in case of private
API). Since none of the existing uses really strikes this author as
particularly convincing, remove them all.
All these classes have gotten Q_NODISCARD_CTOR on all their ctors, so
we continue to provide the same true positive warnings, minus the
false positives when returning from functions, at least on the
majority of compilers (and it's not as if all compilers interpreted a
class-level [[nodiscard]] as a trigger to warn on the initial example
of this commit message).
Task-number: QTBUG-104164
Pick-to: 6.6
Change-Id: I163356486e7c80f9d69bf67023010a88233fe662
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QGtk3Theme uses the GTK button foreground as a default for the
WindowText color role. When a GTK3 theme has no specific color for the
entry text, this can lead to text on certain assets looking darker
and thus disabled.
This discontinues usage of the button foreground for the window text.
Finding the WindowText color role in QPlatformTheme::SystemPalette now
follows the following logic:
(1) GTK normal entry text is used if specified. This is the preferred
option, copying GTK behavior.
(2) If (1) is not specified, the GTK default text color is used, making
WindowText equal to Text.
(3) If neither (1), nor (2) are specified, the WindowText color role is
taken from qt_fusionPalette, where it is also equal to Text.
The SystemPalette is used as a default template for all other control
or widget speicific palettes. The rules above therefor apply to all
screen assets (unless they use a JSON file to specify a their
individual WindowText).
[ChangeLog][QGtk3Theme][SystemPalette][WindowText] Default to GTK
Entry Text / Normal Text / qt_fusionPalette
Fixes: QTBUG-114600
Pick-to: 6.6 6.5.2 6.5
Change-Id: I4c96ac7d096526faf4c2feee436753990c6c9f92
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Explicitly check that at least CMake 3.21 is used when building Qt or
when using Qt in a project.
This only affects macOS and iOS builds.
We check for 3.21 instead of 3.21.1 as described in the documentation
to avoid an error like:
Policy VERSION range "3.21.1...3.21" specifies a larger minimum than
maximum.
Until the technical limitation is addressed, if someone does end up
using 3.21.1, another existing check for "unsuitable" cmake versions
(as opposed to minimum required) will let them know they should use
something newer.
Amends 1cf3295cef321c9a587af2f2de7740c0cd3ca743.
Pick-to: 6.6
Fixes: QTBUG-114869
Change-Id: I2a479baaa63cfbe23af187cf0796e1c00042692b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Use std::unique_ptr to manage items tree memory allocations. This also
use the new string literals operator.
Change-Id: Iab002b5dc612b75cef0be10862e263c6c6c013c1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Pins the vtable to a single TU and therefore prevents duplicate
vtables, -Wweak-vtables warnings and false-positive dynamic_casts.
This requires exporting QGenericRunnable, which hopefully won't
also export the nested class.
Pick-to: 6.6
Task-number: QTBUG-45582
Change-Id: Ie1f29d25b0dcdee7654c33c497e8e0350d12e311
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Mobile Safari generates touch pointer events with negative
pointer id's, which causes processTochEvent() to skip
the event instead of synthesizing a mouse event.
Ensure that the id's are always positive by taking the
absolute value of the event.
Pick-to: 6.6 6.5
Change-Id: I1514329dc76ecc4b9103f7deca9642aaf304df8b
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Newer msvc gives C4309 warning for 'initializing':
truncation of constant value
Warning would go away if we had 'enum foo: unsigned'.
Disable the warning for problematic enums is not enough
as it also complains about headers coming from windows sdk
like:
C:\Program Files (x86)\Windows
Kits\10\include\10.0.22621.0\shared\wtypesbase.h(395): warning C4309:
'initializing': truncation of constant value
Note 10.0.22621.0 is the latest sdk already.
Do not disable language extensions for header clean target.
This reverts commit 8bf602518d
Task-number: COIN-1059
Fixes: QTBUG-114931
Pick-to: 6.6
Change-Id: Ifc3883f88a6bd52794a37dc640eca99c158a40e0
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
After fixing the data type for D24S8, we can now implement attaching
depth and stencil (with the same texture).
For Metal we need to set a stencil flag correctly.
This allows using D24S8 in the manual test, which is likely the format
that is going to be commonly used when setting up multiview with
Qt Quick.
Fixes: QTBUG-114904
Change-Id: Ife425c6cb3e09bfe40092c841b78f7a93bb6a4cd
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Cannot just do like with other APIs and expose a view of multiple
array layers. The only option is to use the multiview-specific API
and specify layers 0..view_count-1 in the depth texture.
This allows having depth in a multiview render pass with OpenGL.
Note that this does not cover stencil. D24S8 does not work, so
we may need to explore having a dedicated, separate stencil
texture.
Task-number: QTBUG-114896
Change-Id: I06ede1d77fef199148d595a55d144c96dc3cbc9d
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
...and expand the docs a bit.
Task-number: QTBUG-114896
Change-Id: I969c3aa2fa72a242e275e4b6dd996df20d1cd2ab
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Behave identically to Vulkan, i.e. create a view that spans all array
elements. (except when the range is set)
This becomes relevant with multiview, where the depth/stencil attachment
the render target must be set up with a texture array as well, similarly
to the color attachment. But applies even to D3D11, even though it is
not common to use a texture array there, but it's possible.
Task-number: QTBUG-114896
Pick-to: 6.6
Change-Id: Ieda8475500b0553f8c14aa9ecad57001b9714d49
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Made this change because there was no example of the interaction
between QBindable and non-bindable properties.
Pick-to: 6.6 6.5
Task-number: QTBUG-114689
Change-Id: Ief7662f8af5e6fab32491418fa35f0daa937819d
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Make sure that QT_ANDROID_DEPLOYMENT_SETTINGS_FILE is expanded
correctly and completely when using it in custom commands.
Task-number: QTBUG-114888
Pick-to: 6.5 6.6
Change-Id: I87c9cb052ea6afedd129fec0a1c415ad38e8eeb5
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
This is similar to and extends the prevention of thread cancellation
introduced by commit ba05af82d3. This
prevents the situation in which a signal gets delivered (usually because
of a crash) and the parent process' handler is run, doing things it
shouldn't between vfork() and execve().
Most C libraries (all that I've investigated) unblock SIGABRT on
abort(), so this doesn't affect them. Likewise, on most OSes, crashes
ignore the signal block and terminate the application -- Darwin appears
to be an exception, but vfork() is not enabled there. Both situations
are tested by terminateInChildProcessModifier().
Task-number: QTBUG-113822
Change-Id: Ib5ce7a497e034ebabb2cfffd17628ca33969b7af
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Simplify the code a little bit.
Change-Id: I7fdb14e676c5b0aa8752b6ee17f0644056ddfcea
Reviewed-by: Timothée Keller <timothee.keller@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The 3-arg connect is error-prone and makes the lifetime of the
connection unclear.
Change-Id: I99aa3575a7f901ac52f451f9ef51aa903640d097
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The 3-arg connect is error-prone and makes the lifetime of the
connection unclear.
Change-Id: I4e518dd4a9733cc0a42b02639cce9c6136ad5afc
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Replace const char * based connect statements by modern API and remove
'_q_' slot prefixes.
This requires explicit disconnection in the destructor -> add.
Replace bool traps for layouting and removing buttons by enum classes.
Replace if/elseif event handler by switch.
Replace iterator typedef with auto.
Encapsulate logic to ensure defaulting to first accept button in a
member function for better readability.
Remove dead code.
Move private header declaration from cpp to a new _p.h.
Task-number: QTBUG-114377
Pick-to: 6.6 6.5
Change-Id: I8a2bc355e3816c3c826c10cd96194c89bf0ae510
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
There are two temporaries, reply.arguments() returns a temporary QList
and list.at(0) returns a temporary reference to the first element. The
local reference variable would only extend the lifetime of the temporary
object it's bound to, list.at(0), but not the temporary list itself.
Even though this a false positive in this case because QList is
implicilty shared, the compiler can't tell the difference and the fix is
simple.
tests/auto/dbus/qdbusabstractadaptor/tst_qdbusabstractadaptor.cpp:1845:21:
warning: possibly dangling reference to a temporary
[-Wdangling-reference]
1845 | const QVariant &retval = reply.arguments().at(0);
| ^~~~~~
tests/auto/dbus/qdbusabstractadaptor/tst_qdbusabstractadaptor.cpp:1845:50:
note: the temporary was destroyed at the end of the full expression
‘QDBusMessage::arguments() const().QList<QVariant>::at(0)’
1845 | const QVariant &retval = reply.arguments().at(0);
| ~~~~~~~~~~~~~~~~~~~~^~~
Pick-to: 6.6 6.5 5.15
Change-Id: I03d54b56769cbd0f9f1165e4679ec4947267181a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
So no-one 'fixes' the test by pinning synchronizer.futures() into a
named variable or collapsing the two lines into one. Both would break
the premiss of the test.
Amends e8dcbaaaf6.
Pick-to: 6.6 6.5 6.2
Change-Id: I7a98c382a7db0bf3ff369dcaf61af0942796d6a3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This fixes a crash while parsing an XML file with garbage data, the file
starts with '<' then garbage data:
- The loop in the parse() keeps iterating until it hits "case 262:",
which calls fastScanName()
- fastScanName() iterates over the text buffer scanning for the
attribute name (e.g. "xml:lang"), until it finds ':'
- Consider a Value val, fastScanName() is called on it, it would set
val.prefix to a number > val.len, then it would hit the 4096 condition
and return (returned 0, now it returns the equivalent of
std::null_opt), which means that val.len doesn't get modified, making
it smaller than val.prefix
- The code would try constructing an XmlStringRef with negative length,
which would hit an assert in one of QStringView's constructors
Add an assert to the XmlStringRef constructor.
Add unittest based on the file from the bug report.
Later on I will replace FastScanNameResult with std::optional<qsizetype>
(std::optional is C++17, which isn't required by Qt 5.15, and we want to
backport this fix).
Credit to OSS-Fuzz.
Fixes: QTBUG-109781
Fixes: QTBUG-114829
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I455a5eeb47870c2ac9ffd0cbcdcd99c1ae2dd374
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
For easier debugging, e.g. to print out value.len and value.prefix.
Pick-to: 6.6 6.5 6.5.2 6.2 5.15
Change-Id: Ib0eed38772f899502962f578775d34ea2744fdde
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
As requested in code review. Big improvement, code-wise.
tst_Sleep::wait() was failing on the CI, so be more accurate by using
QElapsedTimer::durationElapsed(), which returns nanoseconds.
Pick-to: 6.6
Change-Id: I5bed6d6bd768adfdecab2475e6cbe245c20aabd7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The syncqt tool was originally designed to run at build time, as a
part of dependency chain of Qt modules. This works well unless we need
the code model of the Qt project in IDE, since Qt source code actively
uses header aliases, and creating them at build time breaks the code
model until the initial build is done. So we made syncqt the configure
time tool to not break the developer experience.
It's more likely that developers build Qt using command line or don't
need the code model before the first build. So running the tool at
configure time should be optional.
QT_SYNC_HEADERS_AT_CONFIGURE_TIME switches the "mode" of the syncqt
tool from build time tool to the configure time tool. Without the
option enabled build procedure runs all the syncing targets at build
time only. The exception are the developer builds, if the
'-developer-build' option is enabled, QT_SYNC_HEADERS_AT_CONFIGURE_TIME
is set to TRUE by default. This gives better development experience for
the developers that don't use the code model in their IDE or don't
require it before the first build is finished. Also this build time
mode is preferred for the CI or similar build procedures where code
model is not required at all.
By default, the option initialized from the
QT_INTERNAL_CONFIGURE_FROM_IDE CMake variable.
TODO: The option is forced to TRUE for the static Ninja Multi-Config
builds. See QTBUG-113974 for details.
[ChangeLog][Build System] When building Qt from sources, syncqt and Qt
header files are now created at build time, not configure time. This
should speed up the configuration step. You can set the CMake variable
QT_CONFIGURE_TIME_SYNC_HEADERS to ON to use the previous behavior,
though. The old behavior is also preserved if cmake/configure is run
from inside an IDE - Qt Creator, Visual Studio Code, and CLion are
currently detected.
Task-number: QTBUG-111163
Task-number: QTBUG-109792
Pick-to: 6.6
Change-Id: Ib61bda9546e58492be874a8591c37e100313d02c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Vcpkg detection is enabled by default, but we did not have a flag to
disable it, and it was not showing up in config.summary either. By
adding a -vcpkg flag, we get to use `-no-vcpkg` when necessary, as well
as adding an entry to config summary indicating whether vcpkg is in use
or not. Besides `-no-vcpkg`, one can pass `-DQT_USE_VCPKG=OFF` to cmake
command in order to disable the automatic vcpkg detection/integration.
[ChangeLog][configure] vcpkg detection, and integration can be disabled
by passing the -no-vcpkg flag to the configure command, or by passing
`-DQT_USE_VCPKG=OFF` to the cmake command.
Pick-to: 6.6
Change-Id: Ide8da70a7b473ec23995104d162356e75e6d1240
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
