qt/qtdeclarative.git, branch 5.6

Correctly set this object when calling scope/context functions

2018-05-25T09:15: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 
(cherry picked from commit b2420780df98cb3c98553da18a5b1bc5b64e9e83)

Rebuild QQmlData::propertyCache if deleted by another engine

2018-05-08T06:36:16+00:00

QQmlData is shared between engines, but the relevant QObjectWrapper is
not. Since 749a7212e903d8e8c6f256edb1836b9449cc7fe1 when a
QObjectWrapper is deleted it resets the shared QQmlData propertyCache.

In most cases the propertyCache except when a property updated in an
existing binding in the first engine, where it currently asserts.

Task-number: QTBUG-61681
Change-Id: I6efdc506e5c7e30b95cda1be282afa9feb781cd2
Reviewed-by: Simon Hausmann 
(cherry picked from commit ab5d4c78224c9ec79165e8890e5f8b8e838e0709)

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

2018-03-15T10:29:39+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: Id27bb44eccbf39608ae8cebab634c8bcd4c8adfc
Reviewed-by: Simon Hausmann

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

2018-02-26T14:00:58+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.

 Conflicts:
	src/qml/compiler/qqmlpropertyvalidator.cpp
	src/qml/qml/qqmlvmemetaobject_p.h
	tests/auto/qml/qqmllanguage/tst_qqmllanguage.cpp

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-23T11:39:38+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.

 Conflicts:
	src/qml/types/qqmllistmodel_p_p.h

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

Fix 2 use-after-free problems in the ListModel

2018-02-22T08:22:31+00:00

This is a combination of 2 commits that went into 5.9. They cannot be
cherry-picked however, because some c++11 constructs were used. Hence
this combo commit, which is a squashed version of those two commits that
have the c++11 bits replaced by Good Old boilerplate code.

Original commit 1 (e29ffa179e9920443a23e2fcb3f0694df32e8a68):

Fix use-after-free when removing elements from a ListModel

Detaching delegate instances from model items is done after the
destruction of said model items. The problem is that after the model
item is destroyed, it will emit a change/destroyed signal. As the
delegate is still referencing the item, this will result in a
use-after-free. To provent that, the items are kept around until after
everyone (notably the delegate model) has been notified of the removal.

[ChangeLog][Qt][Qml] Fix possible use-after-free when removing items from a ListModel through JavaScript.

Original commit 2 (163c515783877b8b0ffb8b5c1bab288addee9745):

Fix use-after-free when clear()ing all elements from a ListModel

Same problem as the problem with remove(), so now clear will call into
remove to do the correct thing.

[ChangeLog][Qt][Qml] Fix possible use-after-free when clearing all items from a ListModel through JavaScript.

Task-number: QTBUG-63383
Change-Id: I9a6bdf65da63b33833f18c80e74ad7bb93409627
Reviewed-by: Simon Hausmann

Fix memory leak with ListModel.get

2018-02-13T10:27:57+00:00

This is a regression introduced with commit
3cc589c98390992e3ee8a7970dc2913ea857d623, which in turn fixed a leak
with QV4::QObjectWrapper objects. Unfortunately the allocate() call into
the persistent (weak) value storage in the list model introduced a leak
of the weak value itself. This is fixed by replacing the free standing
weak value allocation with the use of the existing jsWrapper weak value
in the declarative data (QQmlData). That weak value is freed property in
the destroy() method of the QV4::QObjectWRapper. The extra QQmlData
allocation is hidden behind a unified allocation, similar to what we do
in void QQmlType::create(QObject **, void **, size_t) const.

Task-number: QTBUG-66189
Change-Id: I5351e3e484542709a6b210e84aa19b14d28e11ad
Reviewed-by: Lars Knoll 
(cherry picked from commit 22d43f74e264626d0c28654c42c91839f9de45b5)
Reviewed-by: Erik Verbruggen

Fix performance issues when handling layout changed in Quick item views

2017-11-16T08:47:54+00:00

When the layout changes, we mark all rows as changed but do not track
where the individual rows get moved.

The only reason why one would want to track the moves is to persist
the current item selection across a layout change. But even the previous
code did not achieve that. I'll create a follow up patch to this one
that also implements this behavior as seen in Qt Widget item views.

Note that removing this code brings a tremendous performance win
on larger models. The repeated calls to _q_itemsMoved triggered O(n^2)
behavior in the number of top items in the model. Even with "only"
tens of thousands of items in the model, a layout change became very
costly and took seconds on a beefy modern desktop machine.

Calling _q_itemsMoved in a loop is bad because it:

- leads to O(N^2) behavior within QQmlChangeSet when merging the small
  moves into the item view's current change set
- potentially triggers tons of binding/property updates when the cached
  model indices are updated in _q_itemsMoved

Removing this slow path, I did not yet find a behavior change to the
previous code. Instead, it just does it all much faster.

Change-Id: I67fa99a1c5d8e05d17497d29391da9458bd9bdd0
Task-number: QTBUG-51638
Task-number: QTBUG-45674
Task-number: QTBUG-53677
Reviewed-by: Daniel Vrátil 
Reviewed-by: Robin Burchell 
(cherry picked from 84f61dd2d2b0140814b39a2c5238a6e31c49abd7)
Reviewed-by: Shawn Rutledge 
Reviewed-by: Ulf Hermann

Bump version

2017-09-21T10:25:36+00:00

Change-Id: Ic878796354a42cb5b6ba29b272c603ce762cf232

QQmlTypeLoader: Guard enableProfiler() against QT_NO_QML_DEBUGGER

2017-09-12T08:45:46+00:00

If debugging is disabled, enableProfiler() is an inline empty function.

Task-number: QTBUG-63118
Change-Id: I28fa7b7d3390482e7b0cc6419c5a1f47a5b9916f
Reviewed-by: Simon Hausmann