| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want all further imports to be relative to the redirected URL, not
the base one.
Note that this will incorporate any prior URL interceptions into the
final URL if a redirect happens. We don't really want this to happen
because the result of interception is not meant to be the base for
further URL lookup. However, as interception occurs before redirection,
this is unavoidable. Don't use URL interceptors on remote URLs.
Task-number: QTBUG-67882
Change-Id: I6693d14c8af8212dda9954d0bd0293c3c85441ef
(cherry picked from commit cda2680d801acce4e221b23e88d9b3c5504f86e8)
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using the VDM or QML list properties as models, the delegate model
injects an intermediate QQmlContext that provides access to the
properties of the exposed QObject as context properties. Before commit
e22b624d9ab1f36021adb9cdbfa9b37054282bb8, that context was marked to be
owned by the parent QQmlContext.
When the reference counting was introduced, that parent became
referenced from the cacheItem (DelegateModelItem), but that intermediate
QQmlContext became floating and was leaked.
This can be observed by running the objectListModel test of
tst_qquickvisualdatamodel with detect_leaks=1 in ASAN_OPTIONS.
The leak is fixed by re-introducing the exceptional case of a parent
holding a strong reference to the child, in just this one case.
Change-Id: Iabc26990d39757b0abe0cddf69e76e88e40fba40
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Michael Brasser <michael.brasser@live.com>
(cherry picked from commit 01df9e5f46fd05a80f8f6fcaa91204e6184ded6f)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We must protect various resources in the type loader with our existing
lock. The QQmlTypeLoaderQmldirContent is now value based, so that we can
release the lock on the shared cache early. Copying it involves
adjusting the refcount of the QHash and QString instances in the
QQmlDirParser.
The safety of this was verified with a TSAN build and the example
supplied in the task. It crashed reliably with TASN errors first and
with this patch it runs without errors.
Task-number: QTBUG-41465
Change-Id: I616843c4b8bdfd65d1277d4faa8cb884d8e77df8
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
(cherry picked from commit a3ad52526f79c1528f170c8affe5af00b68ca61d)
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases, when our simple array data had an offset and
data would wrap around, ArrayData::append would write out
of bounds data into the new array, leading to crashes.
Task-number: QTBUG-51581
Change-Id: I55172542ef0b94d263cfc9a17d7ca49ec6c3a565
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
(cherry picked from commit f495d4b660107536d0a67ba48e88550278f13893)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two ways to use function expressions on the right-hand side
of bindings:
property var somethingPressed
somethingPressed: function() { /* ..press something else.. */ }
signal buttonPressed
onButtonPressed: function() { /* ..handle buttonPress.. */ }
In the former case, it declares a property that holds a function. So on
initialization, the right-hand side of the binding returns a closure
that gets assigned to the property 'somethingPressed'.
In the latter case, the signal handler is explicitly marked as a
function for clarity. So, the handler should not be returning the
closure, but the handler should *be* the closure.
In general, it is not possible to detect if the left-hand side is a
property or a signal handler when generating QML cache files ahead of
time. So for this case, we mark the function as only returning a
closure. Then when instantiating the object, we check if it is a signal
handler, and if the handler is marked as only returning a closure. If
so, we set that closure to be the signal handler.
This patch also handles function expressions in SignalTransition and
function expressions as signal handlers.
Task-number: QTBUG-57043
Task-number: QTBUG-50328
Task-number: QTBUG-50328
(cherry picked from commit 22b13921f8067f8a93164875a4ad59bed85b0400)
(cherry picked from commit dc4d6293f9473c0f03c570430d08867d2d01c6e2)
(cherry picked from commit 21301c1dbb00f4a2cd991e520423ed039b297ffb)
Change-Id: I3008ddd847e30b7d0adef07344a326f84d85f1ba
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <simon.hausmann@qt.io>
(cherry picked from commit aa94c6c0469b0595f483f13ac88459f0035deef9)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <simon.hausmann@qt.io>
(cherry picked from commit c99abf1851bbbfcec11eb77173df620746940ab0)
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <michael.brasser@live.com>
(cherry picked from commit 2659c308792967322564b5088e0e21bb371e0283)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <michael.brasser@live.com>
(cherry picked from commit 44a89492b49f23a975377795dbb7a48916cb5081)
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we remove a property from an object, we shrink the used entries
by one (or 2 when an accessor is defined) by moving subsequent entries
"down" over the removed entry. We also have to set the last entry (or 2)
to Undefined, otherwise any heap objects referenced there would be
retained.
This cherry-pick into 5.9 also fixes an issue where the MemberData was
accessed out-of-bound: some entries stored in memory after the array
were copied in, resulting in invalid pointers, leading to a crash
whenever the garbage collector would run.
Task-number: QTBUG-66090
Change-Id: I75905fafd0d88891820d894a869b9714bc9807e0
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
(cherry picked from commit 9e32901835de1c6729ac8bf228148c1e03c4c5a5)
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
| |
Task-number: QTBUG-58223
Change-Id: Ibc599ac2e62aa60405af0022c7f5bab6eac3e3c4
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
(cherry picked from commit ff08272245c099cadd433c8b5d4f98301f5e585b)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <lars.knoll@qt.io>
(cherry picked from commit 22d43f74e264626d0c28654c42c91839f9de45b5)
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The JS stack is used as a worklist while marking in order to prevent
recursion overflowing the C stack. Now if all contents of an array are
pushed onto the stack, it can easily cause an overflow. To prevent this,
drain the stack periodically.
This is fix that should not go into 5.11, as it's already fixed there by
using a ValueArray that will have this exact behavior.
Change-Id: Id5bd28879f6ef0265344d9a70c25f6c66b067309
Task-number: QTBUG-62087
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
| |
This reverts commit 823428d994b0ec0f6b85288d74554660a51b2406. No more
needed after qt3d commit 78f77f80057b1e77c3f47d52de3e0b3f0c5d8d6e that
took the new API into use.
Change-Id: I4acb707cf363a625ae8e90c4560a0d5140cc4011
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Strictly speaking this is a regression introduced with commit
e22b624d9ab1f36021adb9cdbfa9b37054282bb8, making the QQmlContextData
objects reference counted, especially from the V4 QML context wrapper
objects.
That change (correct as it is) introduced an accidental circular
dependency in the simple scenario of importing a .js file in a .qml
file:
Each time the type in the .qml file is instantiated, we create a
dedicated QQmlContextData for the .js file. If the .js file has no
imports itself, that new context will get the same ctx->importedScripts
JS array as the QML context of the .qml file. That is a strong reference
via QV4::PersistentValue. That array in turn contains the
QV4::QmlContextWrapper that belongs to the imported script, which in
turn holds a strong reference (via refcount) to the script's context.
This patch breaks the circular reference when we perform context
invalidation, as the least intrusive measure.
For the auto-test to work, we must also clear the qmlContext persistent
of the QV4::Script that's used to evaluate the .js file. In subsequent
imports that persistent will be initialized to new values, so it will
only hold a strong reference to the last import, but strictly speaking
that is still a leak - hence also part of this fix.
Change-Id: I3e543c946e5e683425072dc3df7e49ca0e0c0215
Task-number: QTBUG-66189
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Mention (in the detailed description) that Array is indeed supported.
- Provide examples for getting and setting individual array elements,
and how to read the length of the array.
- Properly document the property() and setProperty() overloads that
take an index.
- Link to the overloads where it makes sense.
These changes make the intended workflow for using arrays much more
obvious.
Change-Id: I4657a7b1e2b4c2977120ee8e345ee9ae7d2bbc2d
Reviewed-by: Topi Reiniƶ <topi.reinio@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a regression introduced with commit
3b6eeee177b64eebe240d51be0c7bb5f031471d8 in the 5.9 branch. When
constructing an object with deferred properties and not running
qmlExecuteDeferred, then the deferred data would never get deleted
because the bindings list remains non-empty and we would leak the
deferred data as well as the entire compilation unit behind it.
This happens for example when declaring when instantiating a QML file
with states:
states: [ State { ... }, State { ... }, ... }
Unless every state is entered, its deferred changes property is never
applied (via qmlExecuteDeferred) and thus the defer data is leaked.
Task-number: QTBUG-66189
Change-Id: I1b2119c601d1e0ab4e37f53d4cf2f569586ee883
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace manual use in QQmlData and QQmlData::DeferredData with
QQmlRefPointer.
Due to forward declaration trouble this required declaring a non-inline
constructor/destructor for QQmlData and DeferedData and disabling
copying, so that not every C++ compilation unit including qqmldata_p.h
needs to instantiate the QQmlRefPointer destructor and thus know whether
QV4::CompiledData::CompilationUnit has release(), etc. The out-of-line
declarations however should not have any negative impact as the only
call sites are within qqmlengine.cpp, too.
Change-Id: I2e8295cb0d7f876a5d7d18765dbac285184e6c99
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
This approach tracks object allocations only,
when slots from already allocated memory segment are used.
Change-Id: I514b974d7580c1236264bec96dc1abe594585e86
Reviewed-by: Milian Wolff <milian.wolff@kdab.com>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-62007
Change-Id: I63d5a57163b36bc8629930e1cda8d5afa1e77d15
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
The idea of NaN boxing is to use one single NaN as a "true" NaN, and all
others as a boxed value. So when encoding some NaN, be sure to use that
one "true" NaN. Otherwise, it will be interpreted as an encoded value.
Task-number: QTBUG-65998
Change-Id: Ia6e4641be180f3d626c40a57b473f181358e04db
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
| |
Change-Id: I444137fd10041781df232447b8e2bf712582f079
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When for the QQC code path we do QML type re-compilation, we allocate a
new QV4::CompiledData::Unit. We must make sure that this dynamically
allocated memory is released in QV4::CompiledData::CompilationUnit's
destructor, by ensuring that the StaticData flag is not set.
This isn't directly applicable to the ahead-of-time generated cache file
unit data as they will always be re-generated (and thus the unsetting of
StaticData at the end of createCompilationUnit::createUnitData()), but
I've added a test-case nevertheless to ensure the correct engine
behavior.
Change-Id: I16973d7989567892bf8bf9dd6214bf293055d260
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Commit 3b14e2ffdd8eb4b7f7f4508768b75f2acc399370 replaced the
QQmlRefPointer<QQmlPropertyCache> with a raw QQmlPropertyCache pointer
and added a V4_NEEDS_DESTROY tag. However unfortunately the destroy()
method in the heap class does not decrease the reference count.
Change-Id: I90a8c56cd638592b67aae7041fbb57c879c4146c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When importing modules - in the QML loader thread - with plugins we keep
globally track of the Qt plugins that we have loaded that contain QML
modules, to ensure that we don't call the engine-independent
registerTypes() function on the plugin multiple times. After
registerTypes() we may also call initializeEngine() on the plugin for
the engine-specific initialization, which - as a QQmlEngine is provided
as parameter - must happen in the gui thread. For that we issue a
thread-blocking call that waits until the gui thread has woken up and
processed the event/call.
During that time the global plugin lock is held by that QML loader
thread.
If meanwhile the gui thread instantiates a second QQmlEngine and
attempts to issue a synchronous type compilation (using
QQmlComponent::CompilationMode::PreferSynchronous), then gui thread is
blocking and waiting for its own QML loader thread to complete the type
compilation, which may involve processing an import that requires
loading a plugin. Now this second QML loader thread is blocked by trying
to acquire the global plugin registry lock
(qmlEnginePluginsWithRegisteredTypes()->mutex) in qqmlimports.cpp.
Now the first QML loader thread is blocked because the gui thread is not
processing the call events for the first engine. The gui thread is
blocked waiting for the second QML loader thread, which in turn is stuck
trying to acquire the lock held by the first QML loader thread.
The provided test case triggers this scenario, although through a
slightly different way. It's not possible to wait in the gui thread for
the plugin lock to be held in a loader thread via the registerTypes
callback, as that also acquires the QQmlMetaType lock that will
interfere with the test-case. However the same plugin lock issue appears
when the first QML engine is located in a different thread altogether.
In that case the dispatch to the engine thread /works/, but it won't be
the gui thread but instead the secondary helper thread of the test case
that will sit in our initializeEngine() callback.
This bug was spotted in production customer code with backtraces
pointing into the three locations described above: One QML loader thread
blocking on a call to the gui thread, the gui thread blocking on a
second QML loader thread and that one blocking on acquisition of the
plugin lock held by the first.
Fortunately it is not necessary to hold on to the global plugin lock
when doing the engine specific initialization. That allows the second
QML loader thread to complete its work and finally resume the GUI
thread's event loop.
Change-Id: If757b3fc9b473f42b266427e55d7a1572b937515
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the persistent storage becomes fragmented, we would find the page
with a hole in it, but we wouldn't put it to the front of the page
list. So upon the next allocation we would begin iterating through
firstPage again.
This wasn't quite visible in callgrind as overall not many instructions
were executed, but in perf this function showed up as hotspot because
the search for free pages ends up with a lot of cache misses.
In delegates_item_states.qml this was about ~7% of measured cycles with
perf.
Change-Id: I2bfa337ea9be14d1321756963c72d31336790a0a
Done-with: Erik
Task-number: QTBUG-65708
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allowing types with lowercase names causes ambiguity, as can be seen in
QTBUG-43567 and the comment in IRBuilder::visit(), which explains that
"the grammar can't distinguish between two different definitions" whose
only difference is casing of the first letter.
- Prevent registration (return -1 with e.g. qmlRegisterType()) when a
type name doesn't begin with an uppercase letter.
- Document the uppercase type name rule in more places.
Change-Id: I4e522c65990f418eaafa45a256e3cb07a3e01ba4
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a C++ singleton has an enum with the value -1, we would expose that
value correctly when taking the accelerated property access code path in
the optimizer, but when going through the slower QQmlTypeWrapper we
would return undefined. This turned out to be a silly logic error that
assumed that -1 is not a valid value for an enum and instead indicates
an enum value not present.
[ChangeLog][Qml] Fix -1 as enum value in QML exposed C++ singletons
showing up as undefined.
Task-number: QTBUG-66067
Change-Id: Ib66dad7a4b59822b2c40ad6bd9af4b72469582e9
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Michael Brasser <michael.brasser@live.com>
|
|
|
|
|
|
|
|
|
| |
Create an error via QQmlCompileError and return it instead
of asserting.
Task-number: QTBUG-43567
Change-Id: I0c0741943d30516379eff5f44ed8618a0f0116a4
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-65924
Change-Id: I47b3afbb8235900156c814874d5ae2250cf13da8
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
The Qt documentation is supposed to be valid for older Qt versions too.
Anyhow, the generated attributions are only valid for the exact version
the documentation was generated from, so make this explicit.
Also mention since when the libraries are under LGPL3/GPL3.
Change-Id: Iec8f67e5e43be456cc77283ca6d2a7ebe142f501
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Instead hold a direct pointer to the animation timer and make it's
methods non static.
Change-Id: I6382fd2a1c02464ddb573f0210a14c603fd932db
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
|
|
|
|
|
|
|
| |
It is talking about item() but such a method doesn't exist anymore.
Change-Id: I1935d8b9e88b27a9db1122545a2a82a42d827671
Reviewed-by: Michael Brasser <michael.brasser@live.com>
|
|
|
|
|
| |
Change-Id: Ic2a98a3a4b4362036222df05a92c0bed633c1d1c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The common case is that QQmlProperty is constructed on the property of
an object, not a group property. Therefore we should do the
QVector<QStringRef> split on the property name by '.' only if a dot
exists, and can avoid the allocation and deallocation of the vector.
Shaves off ~1.2% off delegates_item_states.qml.
Task-number: QTBUG-65708
Change-Id: Iffbde176e616beec0ae0a47216360558adc793ee
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Every time we decode a potential binding of a PropertyChanges{} object,
we call qmlContext(this) and we go through a full QQmlProperty
construction (which involves property name decoding by dots and property
lookups), just to determine if we're doing a binding on a property or a
signal. QQmlProperty::isSignalProperty() will only return true if the
property is valid and if it's a "function" type. The QQmlProperty
constructor on the other hand only constructs a valid regular property
if it's _not_ a function type and a signal property _has_ to start with
"on" followed by an upper case character. We can copy this shortcut out
into decodeBinding() to avoid the QQmlProperty construction in the
common case of plain property bindings.
This is also legit in the scope of group properties, as signal bindings
on group properties are not supported (we always use the state's target
object for signal lookup, never the group object).
In addition, avoid creating a public QQmlContext for the PropertyChange
object by allowing for the construction of the QQmlProperty object via
the QQmlContextData, as that's the only data structure we really need.
These two changes used to be separate, but they need to go together to
keep the tests passing, as the property validation and warning issuing
is now moved from decodeBinding() into ::actions() itself.
Shaves off 1.5% off delegates_item_states.qml
Task-number: QTBUG-65708
Change-Id: I32a17d815bd3495a907a51068a971eb7cb69c6ef
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
| |
Change-Id: Ibda07de7a83cf9a1434532c485583b8b49b0a605
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit ca6b787a01ea289bd5c2a3e4ff3c7442a4ff58fc. This
internal API was added as a workaround for Qt Quick Controls 2. It
is no longer needed now that Qt Quick Controls 2 are using deferred
execution.
Task-number: QTBUG-50992
Change-Id: Iaddf22460f091743e1a68acd16813a28f3e82ecb
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Force the use of a global lookup if we know that the
property can and will be found in the global object.
This is possible, as the global object is frozen in QML
mode and can't be overwritten.
Shaves of .5% on the delegates_item_states benchmark, and
will significantly speed up all accesses to e.g. the Math
object.
Change-Id: Ia1e248781a13ebaeb8bc43652e53a6fdde336d0d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Many QML items have more than 32 properties, so we ended
up malloc'ing the binding bit table on the heap quite
often. Extending the inline data to be able to accommodate
for up to 64 properties fixes that.
Change-Id: I90a42d601a5406ffacf2506f1957b0c2080bbb7b
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
After commit cae7975a036352ca4bbcf1381a445362f8e01367 the vtable became
part of the internal class, which meant that for allocating the
V4::QmlContext and the QV4::QmlContextWrapper we had one additional IC
transition upon allocation. We can avoid that by providing a default IC
for both types.
Task-number: QTBUG-65708
Change-Id: I22815a24a8389b59103309806f6ac4ca382405f0
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
QQmlRepeater::clear() had quadratic complexity in the number
of items, because the items where removed from the back.
Fix this by searching the cache from the back as well
as searching for child items to remove from the back.
Change-Id: I92e491a8abf47cee9d382ef15cd2471f722fa6dd
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
| |
In QObjectWrapper::query(), return QV4::Attr_Invalid if the object was
deleted.
Task-number: QTBUG-44153
Change-Id: I53e8be6196489c323b190dbfa20d2dda2a54315e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
| |
Because it doesn't hurt and it makes it easier to use it in
QObjectWrapper::query().
Change-Id: I727ce4b862fa34866513cbb80a221a8a3aeca363
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Remove abs(long) definition, since the #ifdef check no longer works
with QNX7 and QNX < 6.6 is no longer supported.
[ChangeLog][Qml] Enabled ARM64 JIT for QNX7
Change-Id: Ife02f3edb508eddaf15da65954496265366e232d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
| |
[ChangeLog][Qml] Enabled x86-64 JIT for QNX
Change-Id: I41eeff4c3ff687e096098982614a739af8d697f9
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|