qt/qtdeclarative.git, branch v5.9.5

Add changes file for Qt 5.9.5

2018-03-21T07:29:06+00:00

Change-Id: I8a8dd8f55075ce23e0ae85abde2538560d5fa2b5
Reviewed-by: Simon Hausmann 
Reviewed-by: Shawn Rutledge

Fix issue with bindings to aliases that cannot yet be resolved

2018-03-20T07:05:24+00:00

When an alias points to a child object which has not yet been
initialized, it's id won't have been registered yet, so setting up a
binding to it will result in a crash.

The fix is: when setting a binding target fails, and its target property
is an alias, queue them until all bindings have been set up, and try
again.

Task-number: QTBUG-57041
Change-Id: I4dc5a6d25c0a32fed9fd952c955e2006c76be45a
Reviewed-by: Simon Hausmann 
(cherry picked from commit aa94c6c0469b0595f483f13ac88459f0035deef9)
(cherry picked from commit c3db3cfa296dbc5aa198520c1411830d165cd496)

Fix JITted code for jump strict-not-equal undefined on 32bit

2018-03-20T07:05:18+00:00

The generated code for jump-on-strict-not-equal-undefined used the
same logic (but with inverted conditions) as the equal case. For
equality, one can jump to else if the value parts are not the same.
So, for not-equal, if the value parts are the same, it would jump
to the else block if they are the same. Meaning, an encoded int
value of 0 (which is strict-not-equal to undefined) would end up
being evaluated as equal.

Task-number: QTBUG-66832
Change-Id: I5c6b8e9b11be53ae21a7164e0a1e0cbfd204f401
Reviewed-by: Simon Hausmann 
(cherry picked from commit 86702c3be53fda404ebe331207f9062675c952e0)

Fix issue with allocating huge objects in the memory manager

2018-03-08T12:32:38+00:00

We shouldn't allocate objects that are larger than the size of
a standard memory segment through the chunk allocator, as this
can lead to problems when freeing the segment and then re-using
it again.

Instead allocate a private MemorySegment for these objects, and
free it when the object gets garbage collected.

Task-number: QTBUG-66732
Change-Id: Ic24ff65d204977f313ab0adaf7a8132883e525f0
Reviewed-by: Simon Hausmann 
(cherry picked from commit c99abf1851bbbfcec11eb77173df620746940ab0)
Reviewed-by: Erik Verbruggen

Allow setting values in value type group properties in "on" assignments

2018-02-26T14:01:05+00:00

Assigning to a group property inside a property value source or
interceptor as part of an "on assignment" is perfectly valid. That is
because while "color" is a value type property, the on assignment means
we're actually setting easing.type (in the example and test) on the
property value source, not the color, and that one is a QObject. The
same goes for interceptors.

Change-Id: I505a658977a578894d6dfb00bf5c65b41e42b12f
Task-number: QTBUG-56600
Reviewed-by: Michael Brasser 
(cherry picked from commit 2659c308792967322564b5088e0e21bb371e0283)

Fix ListModel.get(idx) == ListModel.get(idx)

2018-02-23T13:47:26+00:00

This is a regression introduced with commit
4876ea6a18ccdfd72014582aa5d50ab9f6b6ec9e. Where we previously always
returned the same JS object, we would afterwards return a new JS object
for every invocation, which breaks reference comparison. As we store the
JS wrapper for the list element in the QQmlData->jsWrapper we can avoid
repeated allocations. In order for that wrapper to keep working after
modifications (insertion, etc.) to the list model, we have to replace
the static element index with a reference to the node model meta-object,
which also has an element index that however is kept up-to-date by the
list model itself.

Change-Id: I4368de6b6d86687fe96fbf73bd60b80b69d7b058
Task-number: QTBUG-52017
Reviewed-by: Michael Brasser 
(cherry picked from commit 44a89492b49f23a975377795dbb7a48916cb5081)
Reviewed-by: Mitch Curtis

Remove superfluous assert when traversing IR

2018-02-22T11:17:39+00:00

When accessing/calling a property on an object, it is possible (and
perfectly fine) for that object to be a constant value. I.e. Undefined.
All code handling such a call do handle constants correctly.

Note: this is a 5.9 specific change, because 5.11 got rid of this code.

Task-number: QTBUG-66027
Change-Id: Ied9d0c9c8f8bf958f8634f7be196900b3ea64861
Reviewed-by: Simon Hausmann

Fix crash when changing from a simple to a sparse array

2018-02-16T08:16:37+00:00

After that change, if we ran out of slots in the freeList,
the last entry would point to the first Value in the value
array, not indicating that we ran out of free slots.

 Conflicts:
	src/qml/jsruntime/qv4sparsearray_p.h

Task-number: QTBUG-65828
Change-Id: I3e57bb7a0c2dc29172a485a6ea957b6ab5ac962e
(cherry picked from commit 16ca5eab9bdd31774dc8e657f217e044640eecff)
Reviewed-by: Lars Knoll

Fix crash with the software renderer and windows with QObject parent

2018-02-15T15:26:35+00:00

When a QQuickWindow is a child of another QObject (such as a Loader) and
is scheduled for deletion using a deferred delete event, then a deletion
via the parent ends up calling the window's destructor, which will
finally end up in ~QObject(), which takes care of removing the posted
deferred deletion event from the event queue.

In the case of QQuickWindow, the destructor - called before ~QObject -
calls windowDestroyed(this) on the SG render loop. The implementation in
the software renderer calls QCoreApplication::sendPostedEvents() with
QEvent::DeferedDelete, which ends up deleting the same window a second
time and resulting in a crash.

I can't see a good reason for the existence of the sendPostedEvents()
call there. It is not present in the other render loops and according to
git blame it stems from the very early first implementation of the
software renderer where surely copy & paste from other render loop code
was involved back then.

The same fix is applied to the single-threaded VG and D3D12 render
loops, as they are most likely copy & paste from the software render
loop implementation.

ASAN trace for tst_qquickwindow::unloadSubWindow() on 5.11 branch that shows
invalid access to the QObjectPrivate/QQuickWindowPrivate, which follows the
QObject in terms of life-cycle:

==4736==ERROR: AddressSanitizer: heap-use-after-free on address 0x617000011778 at pc 0x7fdd211cfbb3 bp 0x7fffecb47ea0 sp 0x7fffecb47e90
READ of size 8 at 0x617000011778 thread T0
    #0 0x7fdd211cfbb2 in QQuickWindow::~QQuickWindow() items/qquickwindow.cpp:1308
    #1 0x7fdd21470974 in QQuickWindowQmlImpl::~QQuickWindowQmlImpl() items/qquickwindowmodule_p.h:63
    #2 0x7fdd21470974 in QQmlPrivate::QQmlElement::~QQmlElement() .../qqmlprivate.h:103
    #3 0x7fdd21470974 in QQmlPrivate::QQmlElement::~QQmlElement() .../qqmlprivate.h:103
    #4 0x7fdd1e24da24 in qDeleteInEventHandler(QObject*) kernel/qobject.cpp:4601
    #5 0x7fdd1e253d2f in QObject::event(QEvent*) kernel/qobject.cpp:1240
    #6 0x7fdd1fbd1d41 in QWindow::event(QEvent*) kernel/qwindow.cpp:2356
    #7 0x7fdd211f778e in QQuickWindow::event(QEvent*) items/qquickwindow.cpp:1628
    #8 0x7fdd1e1a4e3c in QCoreApplicationPrivate::notify_helper(QObject*, QEvent*) kernel/qcoreapplication.cpp:1216
    #9 0x7fdd1e1a508b in doNotify kernel/qcoreapplication.cpp:1157
    #10 0x7fdd1e1a555a in QCoreApplication::notify(QObject*, QEvent*) kernel/qcoreapplication.cpp:1143
    #11 0x7fdd1fb87665 in QGuiApplication::notify(QObject*, QEvent*) kernel/qguiapplication.cpp:1723
    #12 0x7fdd1e1a52fa in QCoreApplication::notifyInternal2(QObject*, QEvent*) kernel/qcoreapplication.cpp:1067
    #13 0x7fdd1e1b6ed2 in QCoreApplication::sendEvent(QObject*, QEvent*) ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:234
    #14 0x7fdd1e1b6ed2 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) kernel/qcoreapplication.cpp:1764
    #15 0x7fdd1e1b8cda in QCoreApplication::sendPostedEvents(QObject*, int) kernel/qcoreapplication.cpp:1618
    #16 0x7fdd210cb034 in QSGSoftwareRenderLoop::windowDestroyed(QQuickWindow*) scenegraph/adaptations/software/qsgsoftwarerenderloop.cpp:100
    #17 0x7fdd211cfb8c in QQuickWindow::~QQuickWindow() items/qquickwindow.cpp:1305
[...]

0x617000011778 is located 632 bytes inside of 704-byte region [0x617000011500,0x6170000117c0)
freed by thread T0 here:
    #0 0x7fdd21a8a9d8 in operator delete(void*, unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe19d8)
    #1 0x7fdd2146fa3c in QQuickWindowQmlImplPrivate::~QQuickWindowQmlImplPrivate() items/qquickwindowmodule.cpp:57
    #2 0x7fdd1e26b252 in QScopedPointerDeleter::cleanup(QObjectData*) [...]
    #3 0x7fdd1e26b252 in QScopedPointer >::~QScopedPointer() [...]
    #4 0x7fdd1e26b252 in QObject::~QObject() kernel/qobject.cpp:882
    #5 0x7fdd1fbcf51c in QWindow::~QWindow() kernel/qwindow.cpp:211
    #6 0x7fdd211d0466 in QQuickWindow::~QQuickWindow() items/qquickwindow.cpp:1297
    #7 0x7fdd211d0644 in QQuickWindow::~QQuickWindow() items/qquickwindow.cpp:1335
    #8 0x7fdd1e2666b4 in QObjectPrivate::deleteChildren() kernel/qobject.cpp:1995
    #9 0x7fdd1e26b329 in QObject::~QObject() kernel/qobject.cpp:1023
[...]

Change-Id: Iffa90d365d02b074e2a78c5be2895c9f86a4b80e
Task-number: QTBUG-66381
Reviewed-by: Shawn Rutledge 
Reviewed-by: Andy Nichols 
(cherry picked from commit 238cc098d785b4fe76fbc8422b340d98ff8c1a1b)

Correctly set this object when calling scope/context functions

2018-02-15T14:23:16+00:00

When a function is called that is in a QML scope or a QML context, set
the 'this' object to the QML scope.

Note: this patch is 5.9 specific. 5.11 has a similair issue, but the
implementation is quite different, so that needs a separate fix.

Task-number: QTBUG-59357
Change-Id: Ia78e012d413c40a094e957f4020502cd055ac286
Reviewed-by: Simon Hausmann