We register QList<T> as sequential container type for any value type T
we get. This way we can always find a type to use for list<t> with t
being a value type. The metatypes are shuffled around so that we have an
easier time associating a type with its list and vice versa.
As QQmlPropertyData's isQList flag denotes both QQmlListProperty<T> and
QList<T> now, we need to use QMetaType::IsQmlList more often.
Conversely, any name given to extra sequential containers registered via
QML_SEQUENTIAL_CONTAINER is explicitly ignored now. As you can do
list<foo> for any type foo now, there is not much of a point in having
further named container registrations for the same type. It would just
make things more complicated. Mind that the name had already been
ignored before, just not explicitly.
[ChangeLog][QtQml] You can now use lists of value types in QML. For
example a property of type list<int> will hold a list of integers.
Task-number: QTBUG-82443
Change-Id: I7bee61cee3963dae5d231bf59f70b8012984371d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Re-defining them for each single sequence object is quite expensive.
Pick-to: 6.3
Change-Id: Ia7a602aada6f9904dd3a72ad5788482576170d9e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It is shorter and encapsulates the exception handling a bit.
Change-Id: I8e2dc0eb3b930e222b8cb4852b73d99ca18a0379
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This saves us some ping-pong between the IDs and the QMetaTypes, and
avoids possible ambiguities if multiple metatypes are registered for the
same C++ type.
Change-Id: I81cec94a9cd05d69927dc884f65574f0ab2ddc22
Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This way, we can avoid the costly id to metatype lookup in case where we
actually need the full metatype.
Task-number: QTBUG-88766
Change-Id: Ibe29b323007f00d2f8d1807fb9b64f9a8f87e807
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
We almost never need to construct a QVariant to do this. Constructing a
QVariant is excessively expensive if you have something simple like an
integer. This also fixes the unexpected "unwrapping" of variants when we
pass them through QJSValue.
[ChangeLog][QtQml][Important Behavior Changes] If you create a QJSValue
from a nested QVariant (that is, a QVariant containing another
QVariant), then, when retrieving its contents again, the outer variant
is not unwrapped anymore. Rather, you get exactly the value you've
passed in.
Change-Id: I8c16eed4f13e8cfdeced0756eef593b3b8e84dd1
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
You get to write QML_SEQUENTIAL_CONTAINER(value_type) now, and
qmltyperegistrar will generate a sensible registration call from that.
A registration might look like this:
struct MyStringListForeign
{
Q_GADGET
QML_ANONYMOUS
QML_SEQUENTIAL_CONTAINER(QString)
QML_FOREIGN(MyStringList)
QML_ADDED_IN_VERSION(3, 1)
};
It's unfortunate that we need to use a metaobject to transfer all of
this information, but there is no other sensible way.
Transform the containers defined in qv4sequenceobject.cpp to use the new
style, and move them out of the builtins, into QtQml. Recognize that
only one of them was ever tested, and add tests for the rest.
Task-number: QTBUG-82443
Change-Id: I3a30f9e27266bb575eea26c5daf5dad1ec461cc5
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This avoids the template explosion and makes the mechanism extendable.
You can now register additional anonymous sequential containers.
Fixes: QTBUG-71574
Task-number: QTBUG-82443
Change-Id: I5b9ed9af1533a3b7df8fc5bb37bbb73b8304e592
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
You can wrap QObject pointers in plain JavaScript.
Change-Id: I246a72a7d5d7b2562e722bf9eafc7880b772a806
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This feature is available without QML, in pure JavaScript.
Change-Id: Iec8a52ed10ed3eeaec24d3955c8c132bf2bd9677
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
No one should remove this at() before Qt6.
Task-number: QTBUG-80535
Change-Id: I464c6f675dc68ad9762fcb594bb4d6ba6bdaf316
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
at() does a range check on the argument. There is no reason to do this
here, and for std::vector this can trigger an exception with interesting
compiler bugs attached to it.
Task-number: QTBUG-80535
Change-Id: I186262de89074a93e68cacec4fba31cc8b8108c8
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
And with that get rid of the old advanceIterator methods.
Change-Id: I969fa89d25df8992a4b08c8c081b91c92ffdfddd
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The old advanceIterator schema was extremely ugly and in addition
not flexible enough to support the requirements for Proxy.ownKeys
and some of the methods in Object
Implemented a new scheme through a OwnPropertyKeys method in the
Object VTable that creates and returns an iterator object. Ported
QJSValueIterator and for-in to use the new mechanism.
There's still many places where we use the old ObjectIterator (that
relies on advanceIterator). Those will be ported in subsequent
commits.
Change-Id: I091a9bea9ff6b2b63630cc336814700757a718be
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Turns out that the overloading of vtable methods and regular
ones is problematic in some cases. So let's rather make it explicit
which methods are part of the vtable, and which aren't.
Change-Id: Ifee32a26104d30f3c82bca8b5a9cdea2d4f4f526
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Change all uses of Identifier to use the new PropertyKey class
and get rid of Identifier.
Change-Id: Ib7e83b06a3c923235e145b6e083fe980dc240452
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>
Pass an Identifier through those virtual methods to unify
the string and integer based versions.
Also add the receiver that's required in ES7
Change-Id: I4e7f01b4c97cc80bcb3c485f6343f28213dc9e6b
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>
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>
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>
Convert most of the methods used QML objects to the new calling
convention. Converted IndexedBuiltinFunction to do the same.
Change-Id: I41b26042c2f56f24988485b06e8ccd214e2573c0
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Avoid allocations on the JS stack if possible
Change-Id: I344cd6dceb6264314f9d22c94db22b22d1d24d14
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
As, this is going to change in a simple stack based structure
to keep pointers to the data to pass to calls.
Change-Id: Ia9aa3f81ee3eeba36affd16aac7b2fe97d59aea9
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
Instead of mimicking a Value. This makes sure that argc now stays
correct even when anything on Value changes.
Most of the change is mechanical: replace callData->argc by
callData->argc().
Change-Id: I521831ae1ffb3966bad6589c18d7a373e13439d7
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Renamed ScopedCallData to JSCall, enforced passing a JS
FunctionObject to it, and added call() and callAsConstructor()
methods to it.
Change-Id: I30db65c9765c2896b5909fe2105c0934c6dad861
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Don't emit any Line instructions anymore, and instead store
the info in a side table in the compiled data, where it can
be looked up on demand.
Change-Id: Idcaf3bf4ee4129fd62f9e717bf1277dc6a34fe19
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
Allow for faster calling of builtins, and completely avoid
scope creation in many cases.
Change-Id: I0f1681e19e9908db10def85a74e134a87fc2e44c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Fix some regressions introduced by change
1ae1eaf59e0475a2dc9c5e22e53e9be19d0f2feb.
Change-Id: I24c1db78634e3beb1ab090325b60e70f788f92a7
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
Change those back again to return a value. This will be required
to avoid creation of Scope objects between JS function calls.
Change-Id: I05cb5cf8fd0c13dcefa60d213ccd5983fab57ea3
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
Instead modify our StackFrame struct to hold the
QV4::Function and have a linked list of those for
the frames.
Change-Id: I8676e16bc51a5ba6cf25a5b3423576d44e8a926a
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
Some parts of the ES6 (and even ES5!) spec specifically require handling
of a property write failure. This will be introduced in followup changes,
as it's going to be rather more involved than this.
Change-Id: Ie482493fcf4780df0e23619650a856421d20bd55
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Ulf Hermann
Assam Boudjelthia
Fabian Kosmale
Volker Hilsheimer
Qt Forward Merge Bot
Lars Knoll
Tasuku Suzuki
Simon Hausmann
Shawn Rutledge
Erik Verbruggen
Ville Voutilainen
Robin Burchell