The qqmlecmacsript required changes, because the call to id makes the
type now known to the QML engine.
Change-Id: I73aed804ae8769c71676b44d8450e1dabf5baa6d
Reviewed-by: Ulf Hermann <ulf.hermann@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>
The tests makes assumptions which simply don't hold anymore,
now that QProperty does automatic type registration, and
the engine supports magic conversions via QSequentialIterable.
Change-Id: I33e8eeca95757686e59da9db5ef5d92041364335
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The Qt version was added in 5.14 "for use as eventual replacement for
QString::SplitBehavior." Move another step cloaser to that goal.
Change-Id: I3214ad6ccaca9dfd4a026589cabeb40cbf4a6298
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The sameValue(Zero) algorithm were implemented according to the
JavaScript specification; however QML has the concept of value types.
For those we need to check equality with the intrinsic isEqualTo method.
This aligns sameValue(Zero) with strict equality in its treatment of
value types.
This fixes Array.includes for value types
Fixes: QTBUG-81825
Change-Id: Idd3e09cbed94bca6ea44f5683610b87d184e432c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
We started to convert containers to QJSValues, so that we could use them
as JavaScript arrays. Unfortunately, this would then lead to a type missmatch
when those same values where to be stored in a property of the container
type. This commit fixes this by converting them back to the original
type.
Fixes: QTBUG-80916
Change-Id: I30a3b03e17c34b171d4a6881dfd7801c13e94d80
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
MemoryManager::collectFromJSStack did push to the mark stack without
checking if there is actually still space available. To fix this, we now
drain the stack once we hit the limit.
The test case is a slightly modified version compared to the reported
one, removing one loop. This was required as our regular expression does
not throw an exception when there are too many capture groups. However,
to trigger the bug, looping was not actually necessary.
Change-Id: I4d00865f25a989c380f4f5b221f4068c80b71d2b
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Previously, the code generator would truncate the stack slots when
writing the compiled function, as that one only had a 16bit field for
them.
Also, add a debug-mode check for stack overflows to the interpreter.
Unfortunately, as it triggers a stack overflow, the test will not
reliably fail without this change.
Fixes: QTBUG-80511
Change-Id: I3019bb2de657ae4c3e1040db798a83533f854bff
Reviewed-by: Paolo Angelelli <paolo.angelelli@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The ES Date spec goes into minute detail about doing various
algorithms in the dumbest possible way (like InLeapYear() calling
DaysInYear(), rather than the other way round) but, in MakeDay(),
leaves the implementation to solve the problem of finding the start of
the first day of a specified month in a given year. So exercise the
freedom we have in that to be a little more robust; and actually check
we have met the conditions the spec requires, returning NaN (as
specified) if not.
Added tests for some denormal dates and date-times and for a date
mentioned in QTBUG-78996.
Task-number: QTBUG-78996
Change-Id: I8d9a841dd1f1d9995273a3de8f6f9130207c7c2b
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The result from component.create() has to be deleted somewhere.
Change-Id: I23135cb639fc316641e399decc740d9f5d445a84
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Otherwise QString::number() will apparently extend "negative" values to 64bits
even if the actual type is only 32bits long.
Change-Id: Ibdecff2fe707616d2254b7e34e08247f0ff52489
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
Most of the rules already had Semicolon at the end, however it was
missing for UiScriptStatement, list properties and UiObjectInitializer.
This change fixes the regression from 5.11.3 to 5.12.0, and keeps the
behavior consistent.
Fixes: QTBUG-77954
Change-Id: I45ef35fab399e3f971444b96d4a9ec6a99e29e09
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
First, let the lexer create a T_FUNCTION_STAR token for "function *",
which makes the job of the parser significantly easier.
Then, by using GeneratorDeclaration instead of GeneratorExpression, we can
avoid the conflicts between UiObjectMember and PrimaryExpression
Change-Id: Ib08918e3977ed1a80cdea0948da80bf37886f7de
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Extends grammar to support generator functions in QML components and
adjusts codegen accordingly
The corresponding test case must be blacklisted in tst_qmlmin, as qmlmin
cannot handle yield statements
Fixes: QTBUG-77096
Change-Id: I47d45dd56289cdf073b41932a585259d3052de04
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Some silly ignoreMessage failures on 32 bit systems..
QString::number((quint32)0xaabbccdd, 16) returns "0xaabbccdd"
while
QString::number((qint32)0xaabbccdd, 16) returns "0xffffffffaabbccdd"
We therefore change to use quintptr (which will follow the quint32
codepath).
Change-Id: I40530d8da83ee43862541f0e87684dc11ed07a53
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Commit 7cb6dce1f3 introduced an
optimization to remove bindings that after their initial evaluation had
no dependencies or errors (such as when accessing properties not set
yet). However when accessing a context property in a silent way -- using
typeof -- then no error state is set and the binding is removed. Any
later change of the context property results therefore in no binding
re-evaluation. This patch skips the optimization on bindings that are
associated with a context that has unresolved names. This fixes the
concrete bug at the expense of disabling further optimizations in the
context if other bindings access unresolved context properties. However
since context properties are discouraged anyway, this may be an
acceptable price to pay.
Change-Id: I95e120a4f71e8ebe0ec1fc44e8703c75f920dd28
Fixes: QTBUG-76796
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
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>
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>
Nobody needs those and we run into integer overflows later on if we
accept them.
Fixes: QTBUG-74048
Change-Id: Ib8ccd05e4bd6f662c38fbe95bf1350f81982e1b8
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Those throw arithmetic exceptions as the result doesn't fit into an
integer.
Fixes: QTBUG-75030
Change-Id: Ibd978848f42cf1c9da1e4af2dc9d7da123ef8f5a
Reviewed-by: Simon Hausmann <simon.hausmann@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>
QRegularExpression is the recommended way to do regular expressions
nowadays. Support assignment of JavaScript regular expressions to
QRegularExpression properties of QObjects and the other way around.
QJSValue::toVariant() will create a QRegularExpression from a JavaScript
RegExp by default now.
[ChangeLog][QtQml][Important Behavior Changes] QRegularExpression is now
supported the same way QRegExp is in QML. QJSValue::toVariant() creates
a QRegularExpression variant rather than a QRegExp one from a JavaScript
regular expression now.
Fixes: QTBUG-73429
Change-Id: I301a02771cd17903406c2bc5c7aaeca6cce629f0
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
toInt32LhsAcc convertes both the lhs and the accumulator to int32. If
the accumulator is not saved, a GC run during the conversion of the lhs
might trash its value.
Fixes: QTBUG-74058
Change-Id: Ic42693061c7d483bb430d77bcc095de6ff9a6843
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The nodes are owned by the SparseArrayData and will be freed whenever an
item is deleted from the array. Therefore, we have to look up the node
for each iteration. This is slightly slower, but at least it doesn't
crash.
Fixes: QTBUG-74188
Change-Id: Id24324a8c83b00b3ad1212cdaabccabd6c8a999f
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We cannot easily find the required stack space to store the extra
arguments without adding a new stack frame. In principle it would be
possible, but heavily recursing on such functions should be a rare
problem.
Change-Id: I1a53a6d29e37ce67aa7bd64acb7b1f41197e84c0
Fixes: QTBUG-72807
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Previously, the loop that generated the string could fail to terminate
with certain numbers as input. Also, the algorithm was duplicated in two
places.
Change-Id: Ie2075148d931e7cfcedb5bcd23af61e2e8afc232
Fixes: QTBUG-73999
Reviewed-by: Robert Loehning <robert.loehning@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This prevents jumping over the resetting of the unwind handler when an
exception occurs.
(cherry-picked from commit 0282b89ec6)
Fixes: QTBUG-73985
Change-Id: I4a4da815f54c13980d239e0492f9b013991cfbd5
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Throwing a TypeError is too drastic. We need to properly deprecate this
pattern before we actually enforce the compatibility.
Fixes: QTBUG-73943
Change-Id: I00313ad7aed4021a7368fd014e2bfc6443b177e3
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
We now check if the given parameters can be converted to the expected
arguments of the function being invoked and throw a type error if not.
Previously we would still invoke the method with random parameters.
[ChangeLog][QtQml][Important Behavior Changes] The parameters passed to
C++ functions from QML are now checked for compatibility with the
expected arguments. If they cannot be converted, a type error is thrown
in JavaScript and the function is not invoked.
Fixes: QTBUG-73405
Change-Id: If16089510d314bb7cdb7d4db86478114c61281a8
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The declarations and usage of runtime functions have seen a number of
changes:
- we don't use the array of method pointers anymore because we don't use
cross-platform AOT JITting
- the check if a method can throw a JS exception was invalid, and was
not used anymore
- value-pointer vs. const-value-ref was inconsistent
This patch cleans that up. By fixing the exception checking, we can now
use it in the baseline JIT to automatically insert those checks. To make
that work correctly, all runtime methods are in a struct, which gets
annotated to indicate if that method throws. (The old way of checking
which type of engine was used is fragile: some non-throwing methods
do not take an engine parameter at all, and those got flagged as
throwing). By using a struct, we can also get rid of a bunch of
interesting macros.
The flags in the struct (as mentioned above) can later be extended to
capture more information, e.g. if a method will change the context.
Change-Id: I1e0b9ba62a0bf538eb728b4378e2678136e29a64
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We want to keep the weak values alive while the destruction callbacks
are running, so that they can still access them. We set them to
undefined later anyway because we expect the destruction callbacks to
mess with the values. Therefore there is no point in also setting them
in between.
Fixes: QTBUG-72137
Change-Id: I83f70230f5b4ad2761c74770f975b14a5ca71f18
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This gives us the opportunity to map the JavaScript null to QVariant's
concept of isNull().
[ChangeLog][QML] Assigning JavaScript null to incompatibly typed
properties generates a compile error now, rather than a runtime error.
Fixes: QTBUG-72098
Change-Id: I72fd1c30d84128c774230eaaea10455b2a0e064c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
A string representation of those is unlikely to be actual JSON, and even
if it is, we don't want to use it as such.
Fixes: QTBUG-72674
Change-Id: I6815366a0176d9725ff4840d3fc545792ce00535
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
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>
When allocating a huge item that requires it's own memory
segment, we were actually not committing enough memory from
the OS.
Fixes: QTBUG-71501
Change-Id: Ic86a648bba4d7f1eeeded78d8de0f0fc1d3a251d
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Try to import let/const variables from JS scripts into QML.
Task-number: QTBUG-69408
Change-Id: Ie58cbc8cd9f8a47f5a077f95b07b5f9e1524707a
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Don't return a name reference if we fail to lookup something in
the scope object, but rather continue trying in the context
object.
Task-number: QTBUG-70315
Change-Id: I73f8aa7b648320434ef0ef37a4c12dca1eb7b209
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
So far we've not been doing the TDZ check for expressions such as
x.name, a[x] and super[x] correctly. Fix this by adding a second
boolean that states whether a tdz check for the subscript is required
and use the first boolean to check the base of these references.
Change-Id: I658cd5b69f001fbdc714f252914ad9749734f027
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This finalizes the refactoring of Object's vtable API. Also added
the receiver argument to the method as required by the ES7 spec.
Change-Id: I36f9989211c47458788fe9f7e929862bcfe7b845
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
JS completion records have some finer details that can only be
seen when using eval(), where the value of the completion record
becomes important.
Fix most of those cases to be compliant with the spec.
Change-Id: I0c8105a8e778de7be3aea151d1bd64243aea067c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Also global variables declared in a .pragma library script
should not be saved in the global object, as the script has
it's on context where those variables live.
[ChangeLog][QtQml] Properties of the JS global object will now
be looked up after local properties in the QML object. This
can lead to runtime incompatibilities if your qml file is named
the same as a property of the global object (e.g. Date.qml).
Task-number: QTBUG-51581
Change-Id: I108aea4c76d088ca8c2124700f91e8eac3fc19f3
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
After the initial enabling of a binding we can quickly determine if
there is a chance whether this binding will be re-evaluated again in the
future as a consequence of dependency changes (properties or
translations). If that is not the case, then we can save memory by
removing that binding again.
One implementation consequence of this change is that such constant
bindings used with the "when" property of states require a proper
reference count increase, which was previously implicit through the
binding association with the target object.
In tst_qqmlecmascript a test that verifies that we don't create run-time
bindings for assignments of literal "null" to QObject pointer properties
now also covers the more complex case where we don't know the property
at parse time. We still evaluate the binding once though and perform one
property assignment.
Similarly on the QtQuick Designer Support API test side a binding such
as
x: Math.max(0, 200)
will not create a persistent binding anymore and needs a tweak to
remain.
On a large scale application this optimization saved up to 5% of all
bindings on start-up (~9000 of ~180000). On Linux x86-64 one binding is
approximately 144 bytes, so the savings are in the range of ~1.2 MB of
heap, as well as reduced fragmentation.
Task-number: QTBUG-64541
Change-Id: Id3653008346fdf36611f5b4c4e82f5f78b5319aa
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Those tests used a shared QQmlEngine so far, leading in some cases
to side effects that last across tests. Fix this by always creating
a new QQmlEngine for each test case.
Also renamed some paths still containing 'nokia' in them.
Change-Id: I4edbae66ac7a7930be66df8294ffbaf98636fb1c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Calling for example Qt.application.arguments.push("...") should throw an
exception.
Task-number: QTBUG-67774
Change-Id: Ifd5cd3357dde510cca77b9b32c9f55f8f72837ff
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
So far, when instantiating QML bindings, the node parameter
could be the same or a child of the body. This will break
badly when we introduce lexical scopeing as that node
could be an AST::Block that opens it's own context.
Changing this requires some smaller adjustments to our autotests,
as error locations will now be slightly different (pointing to
the beginning of the binding, not the beginning of the RHS of
the binding).
Change-Id: I2c536a4fe6d8b549a138cc7967ef034eb2523f3b
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
And make it an enum class. The new name fits better, as it's mainly
used to determine the type of the context when parsing. Also already
added the 'Block' value that will be needed.
Change-Id: I70d963b6a0b22db1a3c607cce6bdd2054b29e000
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Calling Qt.binding() on a bound function object is a valid use
case and used to work until Qt 5.8.
The problem was that we optimized the code in QQmlBinding and
QQmlJavascriptExpression to directly work on a QV4::Function,
so this wouldn't work anymore.
To fix this make sure recursive calls to Function.bind() are
unrolled (so that the BoundFunction's target is never a bound
function itself), then add the bound function as an optional
member to the QQmlBinding and use it's bound arguments if
present.
Task-number: QTBUG-61927
Change-Id: I472214ddd82fc2a1212efd9b769861fc43d2ddaf
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Stringify::JA takes an ArrayObject* but it merely gets the length
property and does indexed get calls. Those work also on array-like
objects such as our sequence wrappers.
Task-number: QTBUG-45018
Change-Id: I4ec4f89a2e09c918fbc2ff1d48ae5915e67ce280
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Some compilers (in this case MingW 5.3) don't manage to properly
disambiguate the template overloads, and try to instantiate the
wrong template function.
Solve this by renaming the one of the template functions.
Change-Id: I3574e617fe96c4bd52920a0127a1dfe39cc3d302
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Commit 86702c3be5 and
e2218f8b5c were submitted directly to the
5.9 and 5.6 branches. As the problem does not exist per-se in 5.11 there
is no fix required. This commit only adds the test coverage for this
issue to avoid regressing.
Change-Id: Ic5f5d56f52f3855d20755f771804025f8a93acd9
Task-number: QTBUG-66832
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
Ask expected, this passes currently. The this object is set to the scope
object in QQmlJavaScriptExpression::evaluate, which
QQmlBoundSignalExpression::evaluate calls.
Task-number: QTBUG-66942
Change-Id: I16a709768f9c798910377a52b5e882bb6d554a5f
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
From now on we prefer nullptr instead of 0 to clarify cases where
we are assigning or testing a pointer rather than a numeric zero.
Also, replaced cases where 0 was passed as Qt::KeyboardModifiers
with Qt::NoModifier (clang-tidy replaced them with nullptr, which
waas wrong, so it was just as well to make the tests more readable
rather than to revert those lines).
Change-Id: I4735d35e4d9f42db5216862ce091429eadc6e65d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This might not be the most useful thing to have, but it's part of JS, so
we better handle it.
Task-number: QTBUG-66027
Change-Id: Ib40c90515a3ffd1d065d962d6c79a5e3960e2703
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
CONSTANT properties are by nature non-NOTIFYable.
The issue behind the regression is caused by the fact that we were
capturing a property regardless of whether or not it was const.
There were two states that captureRequired was expressing:
true: We're reading the property of a QObject, and we're not quite sure
where the QObject comes from or what it is. So, when reading that
property at run-time, make sure that we capture where we read that
property so that if it changes we can re-evaluate the entire
expression.
false: We're reading the property of a QObject, and we know that it's
the scope object or context object, which we know very well. Instead of
registering a property capture every time, we can do that ahead of time
and then register all those captures in one shot in
registerQmlDependencies().
There is a third state that is only relevant when captureRequired is
false: We're reading a property from the scope or context object, but
it's a CONSTANT property, so we don't need to register a dependency
at all.
This patch adds replaces captureRequired with the PropertyCapturePolicy
enum, which accounts for the third state and, as a bonus, makes the
code easier to understand.
Task-number: QTBUG-66361
Change-Id: I6cef1deb76538fbdacf1324b4467403dd40dd7de
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Fabian Kosmale
Ulf Hermann
Qt Forward Merge Bot
Edward Welbourne
Lars Knoll
Liang Qi
Jan Arve Sæther
Simon Hausmann
David Faure
Friedemann Kleint
Christian Ehrlicher
Erik Verbruggen
Jüri Valdmann
Rainer Keller
Shawn Rutledge
Mitch Curtis