Qt 6.5.10-lts release Conflicts solved: dependencies.yaml Change-Id: I30aa1cd656455861044ba1c3c8075f52d20dc2e8
Qt 6.5.9-lts release Conflicts solved: dependencies.yaml Change-Id: I6f892bad653449a1dd0e0c6e66cc74eee8657cda
Qt 6.5.8-lts release Conflicts solved: dependencies.yaml Change-Id: Id2eeb915139bdd1943ffc498173db540f22ca2f3
Implicitly constructing a value from a ReturnedValue muddies the responsibility for ensuring that the gc can find the object. With this change, we disable the implicit conversion. The expectation for lifetime management is now: - If a ReturnedValue is stored on the C++ stack, it must be put into a QV4::Scoped class (or there should be a comment why not doing so is safe). Passing a ReturnedValue to a function should no longer be possible, unless the function takes a ReturnedValue, in which case the expectation is that it stores the value in a place where it can be seen by the gc, before doing anything that could trigger a gc run. Using Value::fromReturnedValue can still be used to pass a Value on, but in that case, the expectation is that there is a comment which explains why this is safe. - If a QV4::Value is obtained from a function call, it ought to be stored in a ScopedValue, too. We currently can't enforce this easily, so this should be checked during code review. A possible way forward would be to disallow returning Values, but that would be a larger change, and is deferred to the future. - If a functions has a QV4::Value parameter, it's the callers' responsibilty to ensure that the gc can find it. Fixes: QTBUG-131961 Change-Id: Iea055589d35a5f1ac36fe376d4389eb81de87961 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> (cherry picked from commit a5feec81934ab0b074d6a8c7621b591851f6b544) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit 64526c5e47a5f7217bced8f5affe29b5f1dc0c99) (cherry picked from commit 1f4193570be1cbff72e103ce9d7633ebef87431e) Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Forwarding the bindability of aliases is a complicated affair because a single alias can encompass two properties (the "core" and the "value type" property). This change adds another flag to discern between "can use the bindable for notifications" and "can install a QBinding on this property". Those are different aspects. Deep aliases can still notify via the bindable of the core property, but they cannot accept a QBinding. Accordingly, when querying the metaobject for a bindable of a value type alias, return the bindable of the core property. This is the one you at least meaningfully install an observer on. The bindable of the value type property would be entirely useless. Amends commit 3ea55bf398412d373daab9c92b1498f45de70e96. Fixes: QTBUG-134688 Change-Id: Ib219657bcbd2e263285d54f8736cada74ac594f5 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> (cherry picked from commit 96a2ab231dc6e817a590cc3490562eeea6b7e862) (cherry picked from commit 2cefd558003f7ca27927ffaef3a79b8bf3d532cc) (cherry picked from commit 77e468677e76c81ba9bfc6a4ab38382c4050d9e7)
Qt 6.5.5-lts release Conflicts solved: dependencies.yaml src/quick/doc/snippets/qml/treeview/qml-customdelegate.qml Change-Id: Ifa297315fa0e6e70d9f26312f9183da4769d18fc
This reverts commit da5933f22c00270ac9083a089686e5c54e0057da. Revert of commercial SPDX license identifiers is required for the Qt 6.5.x opensource releases, Qt 6.5.4 onwards. Change-Id: Ic056fb761f242af0ec4c883ecb35d50804c1c67c Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
If we use connect() to connect signals to other invokables we don't want to see the warnings about extra signal arguments. Amends commit cbe1869fbe7048f34513b201a1d9111a0a64257a. Fixes: QTBUG-131774 Change-Id: Iedec7b7c9f71cf2493ccdc00841e087bd336e028 Reviewed-by: Semih Yavuz <semih.yavuz@qt.io> (cherry picked from commit b7d1fafe5b72616964fb7338e26bfc3857e57490) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit 0c53c4e3d888d296d9366552a07657a11e6cc150) (cherry picked from commit 5fdc9ac9c53e93023dabd2dd309c7e86962ef842) Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
MSVC thinks it can deviate from the standard and fold separate functions into the same code block even if their addresses are taken. This makes the addresses equal and breaks the lookup mechanism. We set up a dilemma for the compiler by explicitly comparing the function addresses and failing when they are equal. Now the new function has "different" code that will however be optimized away. Pick-to: 6.2 Fixes: QTBUG-128843 Change-Id: I42d9f764235b877c5c9e054502ea01a16369d27b Reviewed-by: Sami Shalayel <sami.shalayel@qt.io> Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io> (cherry picked from commit fa26df82d7793c0847996785d4137323c67226d2) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit 126b931c46f5754c157bec494f7f3bca9a8577bb)
The same object can be the context object of a hierarchy of contexts. So far we would only clear one of them, leaving dangling pointers in the others. Clear all the contexts. Pick-to: 6.2 5.15 Fixes: QTBUG-119326 Change-Id: I509f257672813866e3736b51f430f1243a8577f0 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> (cherry picked from commit 27ba69af2f64a8b194655c9fbb276ce981075f75) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit 833f4f6913835a18c37b02bd4784d62cbb4d0701) (cherry picked from commit 477c3c3c25d478caa5b833a9c64f3945b3d3a83e)