| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lookups can (and do) reference HeapItems. This was safe in a
non-incremental gc world, as Lookups are always reachable via their
containing CompilationUnits, which are part of the root set. However,
when using an incremental gc, an already marked Lookup might reference a
new heap item, which then becomes otherwise unreachable.
This is alleviated by the fact that Lookups generally either refer to
something already existing or a freshly allocated string. The latter
however is only safe when we can rely on black allocations during gc,
and the former is somewhat reckless.
Remedy this by employing the WriteBarrier for Lookups. We wrap all
HeapItems in a helper class, which -while trivial itself- can't be used
for direct assignments. Intead, it employs a set method which ensures
that the WriteBarrier is used.
Task-number: QTBUG-121910
Change-Id: I6a0ede66ad044076d2e87f134bc95686cb586aee
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
| |
The type loader belongs to the engine and we must not store it in
engine-independent data structures. We do want the import cache to be
stored in the type registry, though (in a separate change).
Change-Id: I2828f5098b27bf1fc96852fc2bd160db44b109e7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is necessary to make the usage of such IDs actually safe. If we let
local properties override outer IDs, then adding local properties in
later versions invalidates the ID lookups.
[ChangeLog][QtQml][Important Behavior Changes] In QML documents with
bound components, IDs defined in outer contexts override properties
defined in inner contexts now. This is how qmlcachegen has always
interpreted bound components when generating C++ code, and it is
required to make access to outer IDs actually safe. The interpreter and
JIT have previously preferred inner properties over outer IDs.
Pick-to: 6.6 6.5
Fixes: QTBUG-119162
Change-Id: Ic5d3cc3342b4518d3fde1b800efe1b95d8e8b210
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
We already have a scope, and there is no guarantee that the
various calls we do won't cause an allocation, and conseqently
trigger the garbage collector
Pick-to: 6.6 6.5
Change-Id: I31db85e74b986c7d9f9d97b5d409e2030cd5f583
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
This is where it belongs. We need to apply some tricks to avoid
cyclic includes, but that's better than what we have so far.
Also, sort and clean up the includes in the affected files.
Change-Id: Ia7a957d06c0ca284045d831417740c3f9920bc92
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the "Addressable" option to ValueTypeBehavior is set, you can use the
"as" operator to cast a previously unknown type into either undefined
or the given type. We can use this in qmlcachegen to generate efficient
code for further operations on the same type.
In the generated C++ it in fact only works for GetLookup because:
a, We generally don't do SetLookup on value types, yet.
b, We generally don't call methods on value types, yet.
c, We cannot store a union of undefined and a sequence type, yet.
However, getting properties of value types is the most important
application of the new casts so this is well worth it.
As a side effect we can also look up things in potentially undefined
results of other operations now. For example list lookups.
Task-number: QTBUG-94807
Change-Id: Ifdf34f1f3f67b7a0a8953b9ed0e947b74638a28c
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both types have functionality to write themselves back to the properties
they were loaded from on change, but so far we could not nest those
writes.
[ChangeLog][QtQml] You can now assign to properties of nested value
types and to elements of containers from QML functions. You cannot,
however, take references of such values and elements. This is in
contrast to non-nested value types and the containers themselves.
However, passing references of value types and containers around
generally leads to very confusing effects. Don't do this.
Fixes: QTBUG-99766
Change-Id: I74cb89e5c3d733b0b61e42969d617b2ecc1562f4
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far, for each method call we had to allocate a new QObjectMethod as
we didn't have any lookup to cache the methods. Introduce a new lookup
for that and use it for all QObject methods.
Since QObjectMethod contains a pointer to the concrete QObject the
method was retrieved from, some more care has to be taken: If we are
going to call the method right away, we don't need the object since we
always have a thisObject and any further retrieval of the same method
will result in a call again. This enables us to cache the method for any
instance of the same class. When storing the method elsewhere, though,
we need to hold on to the object since you can defer the call or connect
a handler to a signal or similar. For such operations we do need the
object. We can still optimize a bit by re-using the method cache we
build the first time around.
Fixes: QTBUG-95628
Change-Id: I5991180c5e0234cdc179c2b78a43dafc9083e525
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In case of a JS context, we need to do the JS lookup early in order to
override imports with locally defined functions.
[ChangeLog][QtQml][Important Behavior Changes] The precedence between
imports and locally defined functions and variables in JavaScript files
has been fixed. If you import a JavaScript file from a QML file, the
functions inside the JavaScript file should obviously override anything
imported from the QML context. This behavior has been restored.
Pick-to: 6.4
Task-number: QTBUG-91687
Change-Id: I119e3109f96ffad7455daaf1a5f17bad31fa8e33
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Pick-to: 6.4
Task-number: QTBUG-67283
Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We should not invoke the base toString() method if there is an override
in a more specific type. This involves lowering the priority of generic
JS lookups when resolving scope properties, in favor of context and
scope lookup.
[ChangeLog][QtQml] You can now override the JavaScript toString() method
by providing a Q_INVOKABLE method of the same name in your QObject-based
C++ classes.
Fixes: QTBUG-87697
Change-Id: I6190111f4c28e54ce76c391c69c4a921e290e612
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
There was a condition missing in qqml.cpp making most type lookups crash
right away. Furthermore, we need to generate code for type lookups we do
need. Finally, the shadow check should skip instructions we don't need
anymore. Shadowing in optimized-out code is not very interesting.
Pick-to: 6.2 6.3 6.3.0
Change-Id: I34e9de7686528b39a35e59c616e4e28b32a6e031
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
| |
You really should not mess with that after creating the property cache.
Change-Id: I070200772475bb67f539dbbd85a298020b14ca79
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we are dealing with dynamic metaobjects, the QML engine may not
create property caches. We cannot see this at compile time. Therefore,
we need to establish a fallback infrastructure that does the same
operations on plain QMetaObject.
Pick-to: 6.2 6.3
Fixes: QTBUG-101349
Change-Id: I8c936fc077b0018df71196620b6987825253cb39
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Amends commit 90790ef23bb148b4ac4c055bd3c11153b4c9a502. As detailed in
the commit message of that change, we don't know if it's actually safe
to skip the work if we've already set up the lookup before. We should
indeed overwrite it.
Pick-to: 6.2
Change-Id: I27cc4dd256599c292f748b2b70cc2519baabb32c
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a function that performs a lookup is called recursively via the
flushing of initial bindings, we may initialize the same lookup twice.
In that case, make sure to release the old property cache before
overwriting it.
We might suspect that this can only re-assign the same property cache
again and therefore we can skip the whole operation if it has been done
before. Yet, considering the dynamic nature of QML, it's very hard to
guarantee this. There are cases where we have to revert lookups because
the types don't match anymore at the time we call them again. I cannot
rule out the possibility of this happening during initialization.
Therefore, the code doesn't try to be clever about this case and instead
just blindly overwrites the lookup (like it did before, just without
leaking).
Fixes: QTBUG-99025
Pick-to: 5.15 6.2
Change-Id: I536deef282bbff723f79a82e4d9e694c3d2d32df
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Template all of the code and make sure the different query variants do
the same work. There is no reason not to query the namespaced imports if
we are passed a different string type as parameter. If we want to skip
the namespaced imports, that is a separate parameter.
This needs to be picked to 6.2 as precondition for fixing
AOTCompiledContext::initLoadAttachedLookup. We need to pass a
QQmlImport::RecursionRestriction when querying by QHashedStringRef.
Pick-to: 6.2
Change-Id: I98aecc7775036728668cc93f550aa73fdefafe9a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We generally want to use QQmlRefPointer for it, rather than manually
calling addref() and release() all over the place. Also, we can
completely inline its ctor and drop an unused member.
Also, do not keep property caches of dynamic meta objects in type
registry. The dynamic metaobjects will change, and the outdated
property caches will eventually be retrieved.
Change-Id: I8042c85b32f3031b554f97a35c1545a3412d2acb
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
|
|
|
|
|
|
|
|
|
| |
We should not include qqmlglobal_p.h just for the export macros as that
pulls in a number of other things. Rather, include qtqmlglobal_p.h for
that.
Change-Id: Iecb60ef676dd880c0d94360ccef6517ef1ec73bf
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't want to copy metaobjects, but QAbstractDynamicMetaObject forces
us. Rather, use plain QDynamicMetaObjectData, and store a pointer to the
actual metaobject.
This requires us to drop the "isDirect()" optimization for property
access, as we realize that there can be dynamic meta objects which are
not QAbstractDynamicMetaObject. However, this optimization was
questionable anyway. What it did was cache the fact that an object might
have a dynamic metaobject in a flag. Checking this on the object itself
should not be much more expensive, though. On the other hand, an object
might receive a dynamic metaobject individually without us adjusting
flags for its type. In that case we would call the wrong method.
Furthermore, most property access can be done using the static metacall
function anyway.
Change-Id: I5897351253496309721bd38adf3e35a1f069b080
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
| |
There is no reason to branch in the getter, the type of the singleton
cannot change as long as the lookup exists.
Change-Id: I32534c505191d2da797cc94f536aa59e9b96e8ba
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
| |
Such lookups are usually caused by repeaters or similar constructs where
many objects look up something in their parent context. As all those
objects have different contexts, we would constantly invalidate the cache.
Change-Id: I06c7d337d859e5e6a81f6e9a8693b155b2af7498
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
| |
Most of this can be inline, and we never need to copy the actual
identifier hash.
Change-Id: I6468b6b1a571e4854c00c865a2aa57c3b2f0ca8c
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of using a hashmap which maps a QML lists metatype to its list
element's metatype, we can just store a pointer in the list metatype to
the element metatype.
Moreover, listType now returns a metatype. This is a preparation for
converting
enginePriv->rawMetaObjectForType(typeId)
to
metaType.metaObject()
calls once we can actually retrieve the metaobject from QML metatypes.
The QML metatype interface classes are moved into a header, so that Qt
for Python can use the same classes.
This does not affect types registered from C++, as those use a different
mechanism.
Task-number: QTBUG-88766
Task-number: QTBUG-82931
Task-number: QTBUG-87134
Change-Id: I330c2bbe4ac92072a333c001750f7504b56df478
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
| |
Now primitives such as integers and strings should also work.
Pick-to: 6.1
Fixes: QTBUG-85615
Change-Id: I201d1844b7272ca50e32f1e33e9ac357b5e68dfe
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
You should declare functions with formal parameters if you want to use
parameters passed by the signal. We need to generate two different
warnings because there are two code paths by which such parameters are
injected. If we compile with qmlcachegen, it simply inserts a lookup
instruction in to the byte code. This lookup then triggers our special
hack expressly made for signal parameters. If we don't compile using
qmlcachegen, a function declaration with formal parameters is
synthesized. We mark those formal parameters as injected and warn if
we see one of them used.
[ChangeLog][QML][Important Behavior Changes] The automatic injection of
signal parameters into signal handlers is deprecated. This is because we
cannot determine the names of the signal parameters at compile time.
Furthermore, also for human readers it is difficult to discern between
arguments, context properties, properties of the current object, and
properties of the root object of the component. Requiring the signal
parameters to be explicitly named resolves some of this confusion. You
can turn the deprecation warning off using the "qt.qml.compiler" and
"qt.qml.context" logging categories.
Task-number: QTBUG-89943
Pick-to: 6.1
Change-Id: If0a5082adb735a73efd793868b3a55bc7d694cbe
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
|
|
|
|
|
|
|
| |
Fixes: QTBUG-83599
Pick-to: 5.15
Change-Id: I8909f0b2d3eca909512b99c172c8dc5e93e48482
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
| |
This is required to remove the ; from the macro with Qt 6.
Task-number: QTBUG-82978
Change-Id: Iead53d18fd790fb2d870d80ef2db79666f0d2392
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This class is not a private detail of QQmlContext. And it is incredibly
hard to see who owns what in there. Let's add some civilization ...
We enforce refcounting for QQmlContextData across the code base, with
two exceptions:
1. QQmlContextPrivate may or may not own its QQmlContextData.
2. We may request a QQmlContextData owned by its parent QQmlContextData.
For these two cases we keep flags in QQmlContextData and when the
respective field (m_parent or m_publicContext) is reset, we release()
once.
Furthermore, QQmlContextData and QQmlGuardedContextData are moved to
their own files, in order to de-spaghettify qqmlcontext_p.h and
qqmlcontext.cpp.
When the QQmlEngine is deleted, any QQmlComponents drop their object
creators now, in order to release any context data held by those.
Before, the context data would be deleted, but the object creators would
retain the dangling pointer.
[ChangeLog][QML][Important Behavior Changes] QQmlContext::baseUrl() does
what the documentation says now: It prefers explicitly set baseUrls over
compilation unit URLs. Only if no baseUrl is set, the CU's URL is
returned. It used to prefer the CU's URL.
Change-Id: Ieeb5dcb07b45d891526191321386d5443b8f5738
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Being careful, we can now save primitive values inline. We use the heap
pointer of QV4::Value as either QString* or QV4::Value* for complex
types. We cannot store persistent managed QV4::Value without the double
indirection as those need to be allocated in a special place.
The generic QVariant case is not supported anymore. The only place where
it was actually needed were the stream operators for QJSValue. Those
were fundamentally broken:
* A managed QJSValue saved and loaded from a stream was converted to a
QVariant-type QJSValue
* QVariant-type QJSValues were not callable, could not be objects or
arrays, or any of the special types.
* Cyclic references were forcibly broken when saving to a data stream.
In general the support for saving and loading of managed types to/from
a data stream was so abysmally bad that we don't lose much by dropping
it.
[ChangeLog][QML][Important Behavior Changes] When saving a QJSValue to a
QDataStream only primitive values or strings will be retained. Support
for objects and arrays was incomplete and unreliable already before. It
cannot work correctly as we don't necessarily have a JavaScript heap
when loading a QJSValue from a stream. Therefore, we don't have a proper
place to keep any managed values. Using QVariant to keep them instead is
a bad idea because QVariant cannot represent everything a QJSValue can
contain.
Fixes: QTBUG-75174
Change-Id: I75697670639bca8d4b1668763d7020c4cf871bda
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
|
|
|
|
| |
Task-number: QTBUG-77237
Change-Id: I661dc7a23946520c8ad298c39796cb8d0561d80c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/imports/imports.pro
src/qml/qml/qqmlmetatype.cpp
Change-Id: I308436caf55402cb2246cb591c6ac8f83e1febf8
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Just like resolving the lookup initially, we need to set the base also
when hitting the cached lookup code path. The base is then used as this
object.
Fixes: QTBUG-76656
Change-Id: I6f6be05bc9875ddccc6e112e91176a0fa24a8fa1
Reviewed-by: Michael Brasser <michael.brasser@live.com>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/qml/jsruntime/qv4value_p.h
src/qml/qml/qqmlmetatype.cpp
src/qml/qml/qqmltypewrapper.cpp
src/quick/items/qquicktableview.cpp
Change-Id: I684f8e01a711580512848bf1253f39b39fcbf4c7
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
An unqualified name that points to a QML singleton will evaluate to a
QQmlTypeWrapper JS object. A member lookup in such an object is not
guaranteed to always produce the same property. The property cache check
may protect us from that, but we must still retrieve the QObject
singleton for every lookup.
Task-number: QTBUG-75896
Change-Id: Ibd9bac6e5c2047f838758811790b299ace636446
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|\|
| |
| |
| | |
Change-Id: I5d2c3da38df35922b2147c3c0bc55c6c3bae2fe5
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Only the call context contains the signal parameters. However, there can
be any number of nested block contexts in a function. This manifests
itself when the function needs an execution context. The simplest way to
trigger this is attaching a debugger.
Fixes: QTBUG-75393
Change-Id: Iabdc06a9fe7bf88204525d6940b626575fee1579
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Singleton object instances were previously managed by
QQmlType::SingletonInstanceInfo and kept in a shared storage. This caused
concurrency problems when instantiating singleton instances from different
QML engines in different threads.
This patch moves the singleton house-keeping infrastructure to
QQmlEnginePrivate and makes SingletonInstanceInfo immutable.
Singleton objects are stored in a QHash with QQmlType as the key because
the qml type id might be 0 for composite singletons. The public API of
QQmlType is extended to provide more information about singleton types so that
access to SingletonInstanceInfo is not needed.
All internal accesses of singleton objects must now take the same code path via
QQmlEnginePrivate::singletonInstance<T>() which simplifies overall usage of
singletons and scatters less implementation details throughout the code base.
Task-number: QTBUG-75007
Change-Id: I13c5fd21cac2eb7291f2cbcf2c2b504f0f51a07c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|/
|
|
|
| |
Change-Id: Ic135a863581d29a3afb9c6c7f070d2630b3913b4
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is straight-forward to enable, with the minor adjustment that we
need to handle the case where a global lookup is done without a calling
qml context (worker script). We don't know at compile time whether a
script will be imported directly or used as a worker script, so we have
to generate the global qml lookup instruction regardless and handle it
at run-time.
Change-Id: Ia033afa214d919d906c676498dd3eceb1c5639d8
Reviewed-by: Michael Brasser <michael.brasser@live.com>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
If we can determine with certainty that a property cannot be found in
the innermost QML context, then we can avoid one entire iteration for
all future lookups.
Task-number: QTBUG-69898
Change-Id: I2a579aa9f60811a818e45235a60a93fc2ede3206
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-69898
Change-Id: If92a0931bd4d64f6c176e93effb04df85ce27284
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-69898
Change-Id: I94bf1aa85c9b2302894f3224e41de81a456211f9
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
This change addresses in particular qmlbench's fib10.qml, where usage of
properties of the global object needs to go be accelerated in order to
avoid regressing in performance.
Task-number: QTBUG-69898
Change-Id: Ic43c64f4dd5459c4e92f87f03235ea836f971515
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-69898
Change-Id: Ifbd9b3bf8d4b0c82b4c3933912e61eea8e0bb987
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
| |
Use a dedicated lookup type to provide super fast access to engine wide
singleton objects as well as scripts
Task-number: QTBUG-69898
Change-Id: Ie430f48f6576a9171018ef18742dcf6b2adb4310
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When resolving names in the context of QML bindings, we now direct
runtime access to QQmlContextWrapper::resolveQmlPropertyLookupGetter. At the
moment this does basically the same as Runtime::method_loadName, which
we called earlier. However this now provides the opportunity to optimize
lookups in the QML context in a central place.
When performing a call on a scope or context object property, we also
did not use a CallName() instruction - which would have gotten the
thisObject wrong - but instead we use a dedicated
CallScopeObjectProperty and CallContextObjectProperty instruction. These
rely on identifying these properties at compile time, which goes away
with lookups (and also doesn't work when using ahead-of-time
compilation). Therefore the qml context property lookup is using a
getPropertyAndBase style signature and
Runtime::method_callQmlContextPropertyLookup uses that.
For the tests to pass, some error expectations need adjusting. In
particular the compile-time detection of write attempts to id objects is
now delayed to the run-time.
The old code path is still there and will be removed separately in the
next commit (as it is massive).
Task-number: QTBUG-69898
Change-Id: Iad1ff93d3758c4db984a7c2d003beee21ed2275c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch allows QML to access let/const variables defined in JS files.
Detailed changes:
- The recently added ContextType::ScriptImportedByQML is changed to avoid
creating Push/PopScriptContext instructions, similar to
ContextType::ESModule.
- QV4::Module is changed to also work with CompilationUnits which are not
ESModules. In this case QV4::Module will behave as if all lexically scoped
variables were exported.
- CompilationUnit is changed to support instantiating and evaluating
QV4::Modules for non-ESModules as well.
- QQmlTypeLoader is changed to always create QV4::Modules for evaluating
scripts. For the non-ESModule case, the QV4::Module is evaluated inside a
QV4::QmlContext, as before.
- A pointer to the QV4::Module is added to QV4::QQmlContextWrapper, and used
in virtualGet to access the let/const variables in the CallContext. Access
is read-only.
Fixes: QTBUG-69408
Change-Id: I6f299363fdf5e1c5a4a0f1d9e655b4dc5112dd00
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
| |
This is required, so we can get rid of the requirement that
getter and setter live next to each other in the member data.
Change-Id: I2ed57a171628af4dfecd1836d00e958c6bed9d4f
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
|
|
|
|
|
|
|
|
|
| |
Specialize find() into several methods for different purposes.
Prepares for further cleanups and being able to split up
getter and setter for accessor properties.
Change-Id: Id4ec5509ac1a1361e2170bbfc2347b89b520c782
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
|