We need to perform the redirection before inserting imports into
namespaces. Through the redirection we might discover a module that we
have already imported before. In that case we must not import it again.
Pick-to: 6.9 6.8
Fixes: QTBUG-133587
Change-Id: I47a279461763b5397137002a9e7c7d3bfc7ad15d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Those are not mapped to regular QMetaMethods but rather come with
special method indices and need to be resolved separately.
Amends commit a741271dd5
This exposes that the override order between JavaScript extensions and
their base types was wrong. JavaScript extensions do certainly not
override their base types. Fix this, too.
We also need to always specialize the lookups for these calls. It
doesn't actually matter if there is propertyData or not since we branch
off into the special cases anyway when calling them.
Pick-to: 6.9
Fixes: QTBUG-132602
Change-Id: Iea83ce94459b0d0a3bf54731898fd62b9ad46c46
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
`ReferenceObject::init` currently allocates connections to certain
signals to enable a reduction of the amount of reads the
`ReferenceObject` needs to perform, by using the signal to identify when
the data that is being represented was invalidated.
In particular, when the `ReferenceObject` is part of a chain that traces
back to a `Q_PROPERTY`, and that property either has a `NOTIFY` signal
or is a `BINDABLE`, a connection to the signal or a subscription to the
`BINDABLE` is activated.
When one of those is done, we further construct a connection to the
`destroyed` signal of the object that holds the property, to ensure that
a read is performed and our data is invalidated if that object is
destroyed.
The code that performs this process, in `ReferenceObject::init`, was
written with the incorrect assumption that a property either has a
`NOTIFY` signal or is `BINDABLE`, but not both.
In truth, a property might both have a `NOTIFY` signal and be a
`BINDABLE`.
When this is the case, the current code would allocate a connection to
the `destroyed` signal on the same memory block twice, once when setting
up a connection to the `NOTIFY` signal and once when subscribing to the
`BINDABLE`, without ensuring that the previously allocated connection
was disposed of.
To avoid this issue, the code that takes care of setting up the
connections is now exclusive between the two connections path, with a
priority on the `BINDABLE` subscription, as this mirrors the already
existing preference we have when dealing with bindings and is expected
to be slightly more performant.
The documentation for this connection process was modified to add a
small mention of this priority of execution.
Some defensive asserts were added to the relevant connection code, to
ensure that we can catch the construction of multiple connections at
once, which is to be considered a bug.
The code that takes care of disposing of the `destroyed` signal
connection was modified to ensure that we only take into account our
allocation strategy and not our actual connection status, which, while
they shouldn't generally be in discord, might incorrectly avoid a
necessary disposal if they would.
A comment that related to the condition for the disposal was modified to
be more precise with regards to the new condition.
Some test cases were added to `tst_qqmllanguage` to check the leak and
`BINDABLE` preference behavior.
Change-Id: Ibdc657fd857a8838797e47ff235f67cfaeec20de
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Use join's before parameter to only add the foreign-types parameter
to the command invocation if there is actually a list of foreign-types
to handle.
This avoids "cannot open foreign types file" warnings during the build
process.
Pick-to: 6.9 6.8
Change-Id: I142d0fab44201a3314354173ea30d2f90841a6f4
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
MockPlatformTheme::m_colorScheme was initialized to Unknown, which
translated to System theme, which was handled as not Dark theme
in the test case. This worked, if the actual system theme was Light.
However, when the system theme is Dark, QGuiApplication::styleHints
colorScheme is initialized to Dark as well. In this case, the test
case failed, because the styleHints did not change and the Material
style did not receive theme change event, resulting in test failure.
Pick-to: 6.9
Change-Id: If9bd4a942344b19dffe2b3ffb96faf0c18b9e2b0
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
You can now use the QT_QML_GENERATE_AOTSTATS CMake variable to control
whether aotstats get generated in Qt or in users projects.
[ChangeLog][Qml] It is now possible to control whether QML Compiler
statistics (aotstats) get generated by setting the
QT_QML_GENERATE_AOTSTATS CMake variable to ON or OFF. The default value
is ON.
Fixes: QTBUG-131002
Task-number: QTBUG-128323
Pick-to: 6.9 6.8
Change-Id: Ibfd55b22d3d284218053bbf67f654c63a7507bae
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
When we store the QQmlParserStatus for an attached object, we put it
into a vector to call it later. However, the status also contains a
back-reference to the container, so we need reference stability.
That is not given if we use a vector, and the vector needs to
reallocate to grow.
Avoid the issue by using a std::deque, which ensures reference stability
as long as one does not insert in the middle (which we don't). This is
rather suboptimal with MSVC's standard library, but we want a minimal
fix to unblock other patches. Finding a more suitable container can be
deferred to a later point.
Pick-to: 6.9
Fixes: QTBUG-134035
Change-Id: I7c3689ba73060abb47f32a20bc2301b82cf48fa6
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
The GrabTransition enum has no "none" value: there's no reason we need
one for public API. But this test records events and transitions, and
needs a way to record that no grab transition happened. It's just an int
anyway, so QCOMPARE_EVENT simply casts it before comparison; and in any
ternary-if expression using NoGrab, we cast both arms to int.
The warning was
warning: enumerated mismatch in conditional expression: ‘<unnamed enum>’ vs
‘QPointingDevice::GrabTransition’ [-Wenum-compare]
549 | QEventPoint::State::Pressed, itemIgnoreMouse ? NoGrab : QPointingDevice::GrabExclusive);
| ^
Next, there is -Wint-in-bool-context: fixed by surrounding the ternary
if's with parentheses.
Replace C-style with constructor-style casts while we're at it.
Change-Id: I0796abc8e19c1842a6b2f4e343d566ff0cc226e6
Reviewed-by: Matthias Rauter <matthias.rauter@qt.io>
Add code snippet for IntValidator and Doublevalidator in Doc.
Update with suggested improvements.
Fixes: QTBUG-16051
Pick-to: 6.8 6.9
Change-Id: Ia34afb23338ca78a9b853b049f9959f2700b8334
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Some styles are setting `modal: true` in Dialog.qml, which affects the
tab focus order.
This test fixes it, by checking whether the current style uses modal
dialogs or not.
Task-number: QTBUG-133530
Pick-to: 6.9 6.8
Change-Id: I8723e54c25bf487f885a5190c4167e93501453b3
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Due to 76bb559e5f, the QML status change
listener is no longer a functional interface, and cannot be represented
with a lambda. Replace usage of this interface with a fully formed
instance.
Fixes: QTBUG-132461
Pick-to: 6.9
Change-Id: Ib456df209189e9657fb65987e7f5b13f19e7b8f5
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Seems to help with an odd MSVC LTO error:
error C2440: 'static_cast': cannot convert from 'T *' to 'T *'
with
[
T=QObject
]
and
[
T=QQuickItem
]
qtbase/src/corelib/kernel/qpointer.h(75): note: Types pointed to are
unrelated; conversion requires reinterpret_cast, C-style cast or
parenthesized function-style cast
Task-number: QTBUG-133961
Change-Id: Iee9fd1821aaeec305115b8b860c86ced6df530ab
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Adds useful information to diagnose the cause of active focus failures.
The failure message will now look like this:
FAIL! : tst_QQuickMenu::FluentWinUI3::contextMenuKeyboard(Popup.Window) 'firstItem->hasVisualFocus()' returned FALSE. (control: MenuItem_QMLTYPE_1545(0x5db854767310, name="firstMenuItem", parent=0x5db8549a28d0, geometry=0,0 190x30, z=1) activeFocus: true focusReason: Qt::OtherFocusReason activeFocusItem: "MenuItem_QMLTYPE_1545(0x5db854767310, name=\"firstMenuItem\", parent=0x5db8549a28d0, geometry=0,0 190x30, z=1)")
We add both a function and a macro, as this allows the helper to
be stepped into while debugging.
Task-number: QTBUG-133858
Pick-to: 6.8 6.9
Change-Id: I26014ee93f5f053df1ac19ac6e673876abce1258
Reviewed-by: Doris Verria <doris.verria@qt.io>
Re-declaring metatypes is not supported. It worked for built-in types
(it was actually a no-op), but it's not a good idea.
Pick-to: 6.9
Change-Id: I536f590e06906b394066fffd78e7f8fe6fda49ae
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Running clazy on the qt multimedia codebase found a few missing emit
statements in qtdeclarative.
Pick-to: 6.8 6.9
Change-Id: If34411774cda45e2142763c910df04f91b5ad1da
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This includes:
- turning VERIFY_SOURCE_SBOM ON
- adding rules to the licenseRule.json files
- correcting the licensing given via REUSE.toml files
- renaming license files not located in LICENSES folder.
Their name needs to be prefixed with `LICENSE.` to be ignored
by reuse and excluded from the source SBOM. The names are
updated in the corresponding qt_attribution.json
A lot of files are skipped during the license test,
but all are present in the source SBOM.
This is why corrections are needed before turning the
source SBOM check on.
[ChangeLog][Third-Party Code] Renaming the license files with prefix
LICENSE. to have them ignored by reuse tool.
Task-number: QTBUG-131434
Pick-to: 6.9 6.8
Change-Id: I2b3e4750405f13a97b350ee65def30f1330526a3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
It was initially failing in CI. There might be a better way though, so
this patch is separate for easy reverting.
Change-Id: I4ec72bb71927ca10871c8e3c5863141b13fe5472
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
So that ContextMenu can open when e.g. a Drawer is in the scene.
[ChangeLog][Important Behavior Changes][Controls][Overlay] The pressed
and released signals are no longer emitted for right clicks. This is to
allow ContextMenu to work when controls like Drawer are used.
Fixes: QTBUG-132765
Pick-to: 6.9
Change-Id: If329a2ddaaf76e498e7ae2cd48a899fc23dba6b9
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
QQuickMenuPositioner positions child menus to the right of the menu item
that opened it. In additon, the overlap and rightPadding properties
are used to offset the x position, which styles can use to fine tune how
exactly submenus should be positioned relative to the parent menu item.
The parent menu's padding is used, because the submenu's position is
initially set to be relative to the menu item that opened it. When the
position is offset by the padding, it will position itself to the parent
menu, and not just the parent menu item.
7add1868c0 introduced the flipping
behavior for menus that have their popupType set to Popup.Window.
Causing menus that don't have enough space to open to the right side, to
instead open on the left side.
The aformentioned patch used the overlap, but forgot to also add the
leftPadding, when flipping submenus.
Also fix the test tst_QQuickMenu::subMenuFlipsPositionWhenOutOfBounds,
which was previously broken on all styles that modified the rightPadding
property of Menu. 6e327f28c7 introduced a
temporary fix, in order to unblock CI, and this patch should fix it
properly.
Pick-to: 6.9 6.8
Change-Id: I62c58617dbcf27c097009859213cb78eb59a8008
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
[ChangeLog][CMake] The FILENAME_VARIABLE option of
qt6_generate_deploy_qml_app_script, which was deprecated in 6.6.0, has
been removed.
Change-Id: Idb73337c8fab5fe009d500e371855e9fec677c37
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
If you use QQmlApplicationEngine to auto-load translations you need to
make them visible by placing them inside the relevant QML module.
Pick-to: 6.9 6.8
Fixes: QTBUG-116588
Change-Id: I4b768c6ad6ef763a5d6c43aaa794860f7751398a
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It contained quite a few inaccuracies. Also, move the docs for
operator== up, into the same block as the other docs for
QQmlListReference.
Add a link to QQmlListReference to the docs of QQmlListProperty.
Pick-to: 6.9 6.8
Task-number: QTBUG-130705
Change-Id: I4cb2aa1a78215719a4a409c75c0a97aef404ef18
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Alexei Cazacov <alexei.cazacov@qt.io>
While those properties may be of type Component, they don't have to. We
can in fact not resolve anything resembling an ID while inside one of
those objects because we cannot determine the component boundaries.
Amends commit dea8e38d95
Pick-to: 6.9 6.8
Fixes: QTBUG-133460
Change-Id: Iac7294166d38ce591c45c0d31b139a52eda70fc1
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
Replace the use of -1 to indicate unset corner radii with explicit
bitfield flags to track whether each corner radius is set.
The default value for unset radii remains 0.0.
Fixes: QTBUG-120188
Change-Id: If51a0165386a0c474ecd57ef23310d1c28f0f60b
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
The sidebar is intended to be an implementation detail, and thus not
intended to be used by users directly. However, it makes sense for it to
have its properties flagged as FINAL for the performance gain. In
addition, a new signal didn't have a revision.
Found in API review.
Pick-to: 6.9
Change-Id: I82b4314a3cf7f8336efe728a6c8da5d22a52a800
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Creating library qtbase\lib\Qt6Quick.lib and object qtbase\lib\Qt6Quick.exp
mocs_compilation.cpp.obj : error LNK2001: unresolved external symbol
"public: __cdecl QExplicitlySharedDataPointer<class
QFontVariableAxisPrivate>::~QExplicitlySharedDataPointer<class
QFontVariableAxisPrivate>(void)"
(??1?$QExplicitlySharedDataPointer@VQFontVariableAxisPrivate@@@@QEAA@XZ)
qtbase\bin\Qt6Quick.dll : fatal error LNK1120: 1 unresolved externals
Since qtbase ac5ab8ce32c6bd4122ecc690d30eade5c4f4bf2a
~QESDP<QFontVariableAxisPrivate> is not exported, but it should not need
to be. This error is believed to be due to an MSVC bug.
Fixes: QTBUG-133494
Pick-to: 6.9
Change-Id: Ia5fdbf7153251c60f23470d38ad19dde778ebf83
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Zhao Yuhang <2546789017@qq.com>
QML methods have to also be annotated with the \qmlmethod, which this newly
added one did not.
Pick-to: 6.8 6.9
Change-Id: I01f7241130c4f098bc94978e71c83891da4103a4
Reviewed-by: <carl@carlschwan.eu>
Reviewed-by: Aleix Pol Gonzalez <aleixpol@kde.org>
Resolves QDoc warnings of type
Macro '\tab' invoked with too few arguments (expected 4, got 3)
Pick-to: 6.9
Change-Id: I1e0dc56daa9eb3a8565e4d691a4504bfa3d0747c
Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io>
The registration functions that are generally provided by the `qqml.h`
header file, were currently registered under the `QQmlEngine` class
reference documentation.
While it is true that one can access those functions by including
`QQmlEngine`, due to the header file for the type transitively including
the required header, it is only by indirection.
Reorganize the QML documentation to be more precise, by providing a page
for the `qqml.h` header file and by moving the relevant functions there.
A simple documentation block for the "qqml.h" header file was added to
the existing "qqml.cpp" implementation file.
The documentation for the relevant element was moved from
"src/qml/doc/src/qmlfunctions.qdoc", directly to the implementation file
for "qqml.h".
The moved documentation blocks were positioned at the bottom of the
file.
The blocks that referred to an element whose definition resided in the
implementation file were interleaved with the code itself and allowed to
auto-tie instead of being explicitly tied by an "\fn" command.
The documentation for `qmlExtendedObject` and the implementation
conflicted on the sole parameter name.
While this is allowed when passing by an "\fn" command, it is not doable
when the documentation block is auto-tied.
As the documentation block for `qmlExtendedObject` is now auto tied, the
conflict would produce a new documentation warning.
There is no directly apparent reason for the name to be different, thus
one of the two was changed in accordance with the other.
In particular, the name of the parameter in the code itself was modified
as the one used in the documentation block is possibly, superficially,
more precise.
The documentation for some of the elements had code-blocks that use some
Qt macros such as Q_OBJECT or Q_NAMESPACE.
MOC doesn't respect comment blocks and will produce an error on seeing
those macro usages.
Work around the issue by obfuscating their usages through the text
substitution infrastructure for the "\code" command.
All moved documentation was modified to relate to the "qqml.h" header
file to ensure their correct positioning in the output documentation.
The original file containing the elements was removed as it is now
empty.
Certain links that specifically linked to some of the moved elements as
being under `QQmlEngine` were modified to work with the new positioning.
Pick-to: 6.9 6.8
Fixes: QTBUG-132409
Change-Id: I10392174ed635e61947bb6aa729e6786dee8018c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The `QtQmlIntegration` module provides the `qqmlintegration.h` header
that expose a series of macros that simplify the integration and
registration of C++ types to QML.
In the documentation, those macros are currently documented as being
provided by the `QQmlEngine` type in the `QtQml` module.
While it is true that one can access the macros by including
`QQmlEngine`, due to the header file for the type transitively including
the required header, it is only by indirection.
Furthermore, there is no real connection between a `QQmlEngine` and the
integration macros. Indeed you can use a `QQmlEngine` without
integrating any type and you can integrate types without even linking to
the `QtQml` module that provides `QtQmlEngine`.
Thus, slitghly re-organize the QML documentation to move the macros
documentation outside of the `QQmlEngine` reference documentation.
A new file, "macros.qdoc", was created under the general folder that
collects documentation related to the integration of C++ types in QML.
This new file provides a dummy documentation for the `qqmlintegration.h`
header file.
The documentation for the macros that are provided by
`qqmlintegration.h` were moved from "src/qml/doc/src/qmlfunction.qdoc"
to this new file.
Furthermore, the documentation body for each macro was modified to
"relate" to the newly documented header file, allowing them to be
positioned in under the correct element in the output documentation.
Certain links in the qmllint documentation were modified to be adapted
to the new documentation structure, as they were linking to some of the
macros by specifying their position to be under the `QQmlEngine`
documentation specifically.
A small note in the cmake documentation that mentioned the now
documented header file was modified to link to the header file
documentation itself.
In the same note, a non-linking mention to the `QML_ELEMENT`
macro was modified to link to the available documentation for the macro.
The documentation related to the definition of QML types from C++
mentioned `qqmlregistration.h` as the required header to access the
registration macros.
While this is potentially true, as the header will include
`qqmlregistration.h`, it requires linking to the fatter `QtQml` module.
As there might be cases where it is not required to link to `QtQml`
itself, mention that the macros resides in the `qqmlintegration.h`
header.
Pick-to: 6.9 6.8
Task-number: QTBUG-132409
Change-Id: I2ff9c1aa40b6d3cd6f451a4d2a7c2c10a9566f35
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
They are not, in fact, value types. Rather they are special properties
of other types and stored as the underlying type. Also, link the
documentation about both, defining enumerations in QML and defining
enumerations in C++ from that page.
Pick-to: 6.9 6.8 6.5
Fixes: QTBUG-89432
Change-Id: Ic73d7cea352a11c1d7699e655100aad078a77950
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
QQuickWidget can use RHI these days, so remove the "Qt 6 changes" note
that said that applications need to force an OpenGL backend.
Pick-to: 6.9 6.8
Change-Id: I8a7bd22e98b895dc4a12ae052c7f53f930bb3db2
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
We recently introduced an optimization to reduce the amount of reads
that we perform when dealing with QObject-provening properties.
As part of the optimization, we need to connect to the destroyed signal
of the original QObject, to ensure that we do perform a read to
invalidate our view of the data after the object is destroyed.
The receiver of the connection needs to modify the state of a
ReferenceObject that refers to the original QObject.
It is possible for the ReferenceObject to be destroyed before the
QObject is destroyed, so that we want to ensure that the connection we
created is dropped to avoid having the destroyed signal trigger a
callback that tries to mutate the state of memory that was freed.
To do so we need to hold an handle to the connection we introduce from
the ReferenceObject.
Due to the ReferenceObject object living in V4's managed memory, we need
it to be trivial.
As a `QMetaObject::Connection` handle is not trivial, we thus need to
add one layer of indirection by storing a pointer to it.
This means, in turn, that we are forced to perform an allocation for a
`QMetaObject::Connection` that will then copy from the original handle
we obtain.
To avoid the allocation, we instead store the connection in block
memory.
Thus, the handling of the connection that is introduced on an instance
of `ReferenceObject` was modified to store the handle in block memory.
The `onDelete` member, which stores the handle to the connection, of the
heap part of a `ReferenceObject` was modified a correctly aligned,
correctly sized byte array.
The code that takes care of producing the connection was modified to
avoid the allocation, instead directly allocating in the byte array by
placement new.
The code that takes care of disconnecting as necessary, in
`ReferenceObject::destroy`, was adapted to disconnect and destroy the
connection stored in the byte array.
Change-Id: I5472096cb163000545d7f632302df0182511f291
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Generally, QML modules should not require private API. It might have
been the case that generated code (by e.g. qmlcachegen) included private
headers, but this is no longer the case.
This might break code using the commercial only qmslc in direct mode
(which might need private Qt headers), but the general advise has been
to explicitly link against the private module when doing so (and it is
already necessary for other Qt modules, like Quick).
[ChangeLog][Important Behavior Change][QtQml] QML modules created by
qt_add_qml_module no longer link against the Qt6::QmlPrivate target by
default. Modules that intentionally use private API must now explicitly
link against it.
Original-patch-by: Alexandru Croitor <alexandru.croitor@qt.io>
Task-number: QTBUG-87776
Change-Id: I8c4c32673d88bb4d976d65ab10a0dc39f5e49596
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The actual conversion code suggests that we may be creating a shared
list property. However, the assignment code internally won't let that
happen. Test as much.
Amends commit 3108c58b97
Task-number: QTBUG-133047
Change-Id: I66f0f043e0dabd2693aa50a30478461a5db5c5ad
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
By passing the URL of an existing component you can do interesting
things with QQmlComponent and Qt.createQmlObject. You really shouldn't
do that.
Pick-to: 6.9 6.8 6.5
Fixes: QTBUG-119545
Change-Id: Iadad0bacc3269be757b4d02845f9a8d0ec12d39a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
When VxWorks is configured with RTP_MEM_FILL false for performance
reasons, then it is not filling the allocated memory to 0, causing
the QML engine to crash, because it is expecting that it is filled
with 0s. This change handles this scenario by calling memset 0 on
the allocated memory. Qt needs to be configured with
QT_RTP_MEM_FILL define.
Task-number: QTBUG-133305
Pick-to: 6.8 6.9
Change-Id: I885c3cad7d81a11b8a0c125ddc098751b9643392
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Android Studio will default to using JDK21 from Ladybug onwards. This
causes deprecation warnings about settings the source/target
compatibility to Java 8.
The more modern fix would be to use toolchains, but that would
apparently require adding a toolchain resolver. To keep it simple let's
just update the values to Java 17.
Fixes: QTBUG-132802
Pick-to: 6.8 6.9
Change-Id: Ic278a4ea7da8d598cee963dbfce0f6d6c00f0603
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Just to make things prettier and help with testing (as the final string
will be the same in 6.8 and 6.9).
Amends 8b6905704e.
Pick-to: 6.9
Fixes: QTBUG-133493
Change-Id: Ic4e5709e150afba7d2fc502f07ea241f25d78205
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Ulf Hermann
Luca Di Sera
Matthias Rauter
Fabian Kosmale
Jarkko Koivikko
Olivier De Cannière
Shawn Rutledge
Dheerendra Purohit
Oliver Eftevaag
Petri Virkkunen
Mitch Curtis
Thiago Macieira
Tim Blechmann
Lucie Gérard
Joerg Bornemann
Giuseppe D'Angelo
Alexei Cazacov
Magdalena Stojek
Joshua Goins
Nicholas Bennett
Topi Reinio
Qt Submodule Update Bot
Alexandru Croitor
Karim Pinter
Olli Vuolteenaho