aboutsummaryrefslogtreecommitdiffstats
path: root/src/qml/jsruntime/qv4sequenceobject.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Avoid unnecessary read-backs on ReferenceObjectsLuca Di Sera2025-02-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When certain types are passed over from C++ to QML, QML converts them to a QML usable representation that keeps track of the original data. To do so, the QML representation of the object performs read/write-backs when required to ensure that the representation is kept in sync with the original data, by reading the latest data from the source or writing back changes that are performed on the QML side. Generally, the representation on the QML side cannot know when the original data was modified, so that it has to read the data again each time it accesses the representation to ensure that the latest data is available. The reads can be very expensive. For example, the following snippet: ``` JSON.stringify(foo) ``` Where `foo` is, for example, a `QStringList`, might need to read the data multiple times for each element in the list. For representations that provene from a QObject's property that has a NOTIFY signal, it is possible to cut down on the number of reads by reading only when the data was effectively changed since the last read, that is, the NOTIFY signal of the property was emitted. Similarly, if the property is a BINDABLE, we can subscribe to the BINDABLE itself to track whether a change was performed or not. Thus, to reduce the number of reads when possible, `ReferenceObject`, the base representation for objects that perform read/write-backs, was modified to take into account the NOTIFY signal or BINDABLE status of a property when referencing data that originally provenes from a `QObject`'s property on the C++ side. `QObjectWrapper`, `QQmlTypeWrapper`, `ReferenceObject` and `QMLValueTYpeWrapper` were modified with the usual `Q_MANAGED_TYPE` macro, to allow identifying instances of those objects, which is used to enable the new implementation. The intializer for `ReferenceObject` was modified to behave differently when the referenced data comes from a `QObjectWrapper`, which wraps a `QObject` provening from C++, or a `QQmlTypeWrapper`, which can wrap a `QObject` that is a singleton or an attached property. When it is so, and the part of the wrapped `QObject` that is referenced is a property that has a NOTIFY signal or is a BINDABLE, the `ReferenceObject` instance will now connect to the signal or subscribe to the BINDABLE. A newly added flag, `isDirty`, will be set when the signal is emitted and is used to track whether the data has changed since our last read. `QV4::ReferenceObject::readReference`, the base implementation for read-backs, was modified to take into account the new "isDirty" flag. When the flag is not set, we expect to already have the latest data, and thus do not actually perform the read anymore. Furthermore, the same implementation was modified to take care of setting the `isDirty` flag to a correct state after a read is performed. The connection to the NOTIFY signal is performed through the existing `QQmlNotifier/Endpoint` infrastructure, which allows, between others, to connect to signal emitted by a `QObject`, and should be more performant than a naked connection. Similarly, a BINDABLE is subscribed to by using its usual interface. A new callback was added to be used by `ReferenceObject` to allow setting the `isDirty` flag on the signal emission. `ReferenceObject` will now store a `QQmlNotifierEndpoint` or a `QPropertyNotifier`, that will take care of listening to upstream changes and set the dirty flag as required. A few bug-provening test cases where added to `tst_qqmllanguage` to test that the number of unnecessary reads was indeed reduced. Additional test cases were added to inspect certain aspects of the new implementation to ensure that it works in certain common or edge cases. The internal documentation for `ReferenceObject` was modified to mention this new behavior. Fixes: QTBUG-118847 Fixes: QTBUG-127322 Change-Id: Id62979ae4e03910e1165c293837e5d884727dddc Reviewed-by: Ulf Hermann <[email protected]>
* QtQml: Avoid potential gc issuesFabian Kosmale2024-12-181-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implicitly constructing a value from a ReturnedValue muddies the responsibility for ensuring that the gc can find the object. With this change, we disable the implicit conversion. The expectation for lifetime management is now: - If a ReturnedValue is stored on the C++ stack, it must be put into a QV4::Scoped class (or there should be a comment why not doing so is safe). Passing a ReturnedValue to a function should no longer be possible, unless the function takes a ReturnedValue, in which case the expectation is that it stores the value in a place where it can be seen by the gc, before doing anything that could trigger a gc run. Using Value::fromReturnedValue can still be used to pass a Value on, but in that case, the expectation is that there is a comment which explains why this is safe. - If a QV4::Value is obtained from a function call, it ought to be stored in a ScopedValue, too. We currently can't enforce this easily, so this should be checked during code review. A possible way forward would be to disallow returning Values, but that would be a larger change, and is deferred to the future. - If a functions has a QV4::Value parameter, it's the callers' responsibilty to ensure that the gc can find it. Pick-to: 6.9 6.8 6.5 Fixes: QTBUG-131961 Change-Id: Iea055589d35a5f1ac36fe376d4389eb81de87961 Reviewed-by: Ulf Hermann <[email protected]>
* Remove unused include from "qv4sequenceobject.cpp"Luca Di Sera2024-11-061-2/+0
| | | | | Change-Id: I65fe010323475b61fc71f20820c3e30c2ab93801 Reviewed-by: Olivier De Cannière <[email protected]>
* QtQml: Support conversion to QJSValue when constructing value typesUlf Hermann2024-10-311-1/+1
| | | | | | | | | | Anything can be converted to QJSValue, but QMetaType::convert cannot perform the conversion. Pick-to: 6.8 Fixes: QTBUG-130522 Change-Id: I5614db21a0fcc0afa4a605cbd28ea92788aa146d Reviewed-by: Fabian Kosmale <[email protected]>
* QML: Allow conversion between different list typesUlf Hermann2024-07-031-40/+125
| | | | | | | | | | | | | We universally allow this pretty much everywhere else. We should also allow it when evaluating bindings. To facilitate this, generalize the SequencePrototype::toVariant() method so that it works with any array-like and faithfully coerces the elements by the type coercion rules. Pick-to: 6.8 Fixes: QTBUG-126398 Change-Id: I520cd40e5f74bee5ac4b418aa86dc043774efcbe Reviewed-by: Fabian Kosmale <[email protected]>
* Rework the sort implementation for SequencesLuca Di Sera2024-06-061-90/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When QML reads a property with a C++ provenance it sometimes apply certain transformations to work with the property in a JS environment. For example, certain containers, such as `QJsonArray` or `QVariantList`, are converted to a `Sequence`, an array-like object that knows how to modify the container and takes care of reflecting mutations back to the property. `Sequence` provides a specialized implementation for the built-in sort method. Generally, the default sort implementation for an array in JS converts the elements to a string and compares the stringified representation. In the case of `Sequence`, the sort implementation will treats the elements as `QVariant`s and use `QVariant::toString` to perform this part of the sorting algorithm. Due to the way `QVariant::toString` works, this can fail for certain elements. For example, `QVariant::toString` is unaware of how to produce a string from a `QJsonValue`, the type of the elements that compose a `QJsonArray`, thus failing to correctly sort a container with such elements. Other than the `Sequence` implementation, the JS runtime provides, as per specification, a sort method for the Array prototype. Contrary to other methods that are implemented for the prototype, the `sort` method is implemented so that it can only work on values that have a populated `ArrayData`, an optimized storage for certain array and array-like objects. As `Sequences` do not use an `ArrayData` storage for their elements, the method is unable to work on a `Sequence`. To broaden the ability of the sort method implementation for `Sequence` to work more generically, the default sort implementation for the Array prototype sort method was modified to work more generically on objects that do not present an `ArrayData` storage, with an implementation based on the latest draft of the JS specification. The specialized `Sequence` implementation was removed, in favor of `Sequence` delegating to the Array prototype implementation which would now support working with `Sequence`s. While this should be generally slower than the specialized implementation, foregoing some performance, it should allow a more generic foundation for the sort method for `Sequences` or other elements that act like an array but do not use the specialized `ArrayData` representation. Some specialization could later be reapplied to `Sequence` to improve the performances of the implementation. Previously, the Array prototype implementation would directly delegate to `ArrayData::sort`, the sort implementation for the specialized `ArrayData` storage. This was modified to dispatch to an implementation based on generic methods when no `ArrayData` is populated on the object of the sort. The code related to the specialized `Sequence` implementation for sort was removed and the sequence prototype was modified to not present a specialized `sort` property, so as to fallback on the Array prototype one. The `ArrayData::sort` implementation was slightly modified. `ArrayData::sort` would perform a check on the presence of a defined callback for the sorting and throw a type error if the non-undefined element is not callable, as per specification. This check was moved to the Array prototype implementation, to be shared between the specialized `ArrayData::sort` implementation and the generic implementation. As per the spec, the check should be performed as soon as the method is entered and before the receiver of the method is converted to an object. With the check moved to the start of the Array prototype sort implementation this ordering of operations is now fulfilled. The compliance test that checks for this behavior, `comparefn-nonfunction-call-throws`, that was previously failing, will now pass and was thus removed from the list of expected failures for the `ecmascript` tests. A `QEXPECT_FAIL` related to testing the default sort of a `QJsonArray` property was removed from `tst_qqmllanguage`, as the sort is now expected to work correctly. Fixes: QTBUG-125400 Change-Id: I158a9a160b8bdde2b8a06bb349a76469fc25c5a1 Reviewed-by: Ulf Hermann <[email protected]>
* QtQml: Optimize QV4::Sequence's shift() methodUlf Hermann2024-05-281-0/+60
| | | | | | | | Most of the time we have a native shift() operation. Fixes: QTBUG-123882 Change-Id: I1bc50f98f29918a56b5fc70d1644eb99542a3073 Reviewed-by: Fabian Kosmale <[email protected]>
* QtQml: Check for isReference() before trying to write backUlf Hermann2023-09-251-2/+3
| | | | | | | | | | | If we neglect this we get an assert further down the line. Amends commit a824a6f060ec3a0000d7349649a3ab9e0570ecaa. Pick-to: 6.6 6.5 Change-Id: Ib8fd01d329d5b45b27dfe117e168860c6a1d267f Reviewed-by: Semih Yavuz <[email protected]> Reviewed-by: Fabian Kosmale <[email protected]>
* QML: Silence warnings about converting holes in sparse arraysUlf Hermann2023-09-251-2/+3
| | | | | | | | | | | | | | Holes in sparse arrays are undefined when read via get(). QV4::Sequence does not have holes, by design. Therefore, when converting, we fill the holes with default-constructed values. This is on purpose and should not cause warnings. Furthermore, since QVariant::convert() always produces the given type, we don't need to re-initialize the variant afterwards. Change-Id: I46a675dfb71ae9f66858c97a580ec133aabef10e Reviewed-by: Fabian Kosmale <[email protected]> Reviewed-by: Qt CI Bot <[email protected]>
* QQmlType: Re-organize QQmlTypePrivate to reduce memory usageUlf Hermann2023-07-061-1/+1
| | | | | | | | | | | | The iid is only used for interfaces, and re-ordering the members saves some padding. Also, avoid extra indirection where possible. QUrl is only one pointer to begin with, just like QMetaSequence. We can store them directly in the union. Finally, rename the extraData members so that we can easily recognize them. Change-Id: Ia9c524ea65f8137b264a7dfd9459369c90ce1670 Reviewed-by: Qt CI Bot <[email protected]> Reviewed-by: Fabian Kosmale <[email protected]>
* QML: Un-specialcase QStringList and QVariantList conversionUlf Hermann2023-06-301-95/+83
| | | | | | | | | | | | | | | | | | Those are just regular sequences these days. They can be written back. Drop some now-dead code and deduplicate the value type conversion code in the process. We should try the (more common) value type conversion before the sequence conversion, but after all the "simple" conversions. [ChangeLog][QtQml][Important Behavior Changes] Converting a QVariantList to a QJSValue via, for example QJSEngine::toScriptValue() does not produce a JavaScript array anymore, but rather a better suited sequence object that behaves almost like a JavaScript array. The only difference is that its QJSValue::isArray() will return false now. Fixes: QTBUG-113690 Change-Id: Ib176c34d59c45a6b5cff68d029c4b1b87d7aa192 Reviewed-by: Qt CI Bot <[email protected]> Reviewed-by: Fabian Kosmale <[email protected]>
* QV4: Sequence/ListWrapper: implement virtualGetLengthFabian Kosmale2023-03-311-0/+8
| | | | | | | | | Both types can provide a natural implementation for virtualGetLength, which is much more efficient than going through the base implementation in QV4::Object. Change-Id: Iefc870451e1ad54c6dbfd6f73f6a5ff9b7552871 Reviewed-by: Ulf Hermann <[email protected]>
* Avoid duplicate value type creationUlf Hermann2023-02-241-4/+4
| | | | | | | | | | | We can actually produce an uninitialized but pre-allocated QVariant using QVariant::Private. Using the new in-place construction support in QMetaObject, we can minimize the amount of copying necessary for value types. Fixes: QTBUG-108789 Change-Id: I6b748794a6adbf6558e1e3086eab80fcfb3154a0 Reviewed-by: Fabian Kosmale <[email protected]>
* Recursively write back value types and sequencesUlf Hermann2022-10-191-83/+131
| | | | | | | | | | | | | | | | | 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 <[email protected]>
* QML: Track statement locations in sequence and value typesUlf Hermann2022-10-141-4/+7
| | | | | | | | | | | With this in place we can enforce that reference objects we add in the future can only be written back in the same statement as they were created. Task-number: QTBUG-99766 Change-Id: I1c74bd239caa1bb5febd1a3705d8ee29a8fc4249 Reviewed-by: Fabian Kosmale <[email protected]> Reviewed-by: Qt CI Bot <[email protected]>
* V4: Refactor QQmlValueType{Wrapper|Reference} and QV4::SequenceUlf Hermann2022-10-131-77/+99
| | | | | | | | | | | | | Every QQmlValueTypeWrapper is potentially a reference now. Since most were already before, the overhead of checking the vtables at every step was dubious at best. Extract a common base class that handles the reading and writing of object properties employed in both value type references and sequences. Task-number: QTBUG-99766 Change-Id: Idf72d9a20a52366e5c2d0dcd4b3a18072c0ccc41 Reviewed-by: Fabian Kosmale <[email protected]>
* QML: Drop the "succeeded" out parameters from SequencePrototypeUlf Hermann2022-10-071-16/+7
| | | | | | | | | The success of the operation is visible from the return value in all cases. Change-Id: I93177785f76b8078ddd8eeb7d77143993fe80739 Reviewed-by: Semih Yavuz <[email protected]> Reviewed-by: Fabian Kosmale <[email protected]>
* Allow more options for creating value types from JS objectsUlf Hermann2022-09-241-6/+14
| | | | | | | | | | | | | | | | | | | | We allow value types to be created 1. by calling Q_INVOKABLE constructors 2. by setting their values from properties of a JS object Both have to be opted into by setting a class info. If opted into, these options override the existing methods. When a a type can be created by setting its properties, that implies you can also initialize it using an invokable constructor. However, when given a JS object, the properties method is used. We keep this internal and undocumented for now. As the last try (the create(QJSValue) methods and QJSValue ctors) was not that stellar, let's first wait a bit and see if we're getting it right this time around. Fixes: QTBUG-106480 Change-Id: I767230924afcba032d501846cc3263dad57b7bf0 Reviewed-by: Volker Hilsheimer <[email protected]>
* V4: Make ExecutionEngine::toVariant() staticUlf Hermann2022-09-201-2/+2
| | | | | | | | | Wherever we need an engine in there, we also have a managed value to get it from. This relieves us from the requirement to drag an engine around wherever we want to call toVariant(). Change-Id: Ib95d02b5fbf5eaa494214e337c9b700e97e5e0df Reviewed-by: Fabian Kosmale <[email protected]>
* QtQml: Remove unused includes in qml, final partSemih Yavuz2022-09-141-2/+0
| | | | | | | | | | | | | | Drop unnecessary includes detected by clangd-iwyu. Add new includes due to the transitive includes. Also, some of the includes were detected as unused even if they were actually in use. In those cases, use angular brackets instead of "" which deceives the tool not to complain. Affected subfolders: JsRuntime, Qml Fixes: QTBUG-106473 Change-Id: I483da15d42a8e3ce6cd3b654909665fff3075d6b Reviewed-by: Fabian Kosmale <[email protected]>
* Fix array-like methods on V4 sequencesUlf Hermann2022-07-191-91/+101
| | | | | | | | | | | | | We need to properly convert value type lists on assignment and we need to add the "length" property to the own properties. Furthermore, the V4 sequence methods were confused about integer type ranges. We teach them about qsizetype, properly range check everything, and drop the artificial limitation to INT_MAX. Pick-to: 6.4 Task-number: QTBUG-82443 Change-Id: Ie5af1130c9e78e412c171e6fa26a28a6a7a5d498 Reviewed-by: Fabian Kosmale <[email protected]>
* Implement array methods for QQmlListPropertyUlf Hermann2022-07-161-2/+2
| | | | | | | | | | | | | | | | | | The test revealed that the fill() method of JS arrays did not properly range-check its parameters. Fix that, too. [ChangeLog][QtQml][Important Behavior Changes] QQmlListProperty behaves like a JavaScript Array now. You can use map(), reduce(), forEach() etc on it. This also includes a slight change of behavior to the push() method. push() now returns the new list length, and it checks the length to not exceed UINT_MAX. Task-number: QTBUG-58831 Fixes: QTBUG-49613 Fixes: QTBUG-99041 Change-Id: Ia64d73fb704449c280fbbc7ddcf20f4698c82e09 Reviewed-by: Fabian Kosmale <[email protected]> Reviewed-by: Sami Shalayel <[email protected]>
* Use SPDX license identifiersLucie Gérard2022-06-111-38/+2
| | | | | | | | | | | | 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 <[email protected]>
* Allow retrieval of sequences from QJSValueUlf Hermann2022-06-021-403/+373
| | | | | | | | | | | | | | As we can store sequence types in QJSValue, we should be able to retrieve them, too. Move the declaration of the QV4::Sequence struct into a header to make it less of a hassle to identify sequences. Change-Id: I3e45bfe193c669107f90cd6c502765c0c9f60fb0 Reviewed-by: Andrei Golubev <[email protected]> Reviewed-by: Sami Shalayel <[email protected]> Reviewed-by: Qt CI Bot <[email protected]> Reviewed-by: Ulf Hermann <[email protected]>
* Qml: includemocsMarc Mutz2022-04-291-0/+2
| | | | | | | | | | | | Including moc files directly into their classes' TU tends to improve codegen and enables extended compiler warnings, e.g. about unused private functions or fields. Pick-to: 6.3 6.2 5.15 Task-number: QTBUG-102948 Change-Id: Ie39c60a19ba562affe6bd52ba68b38db95298cf3 Reviewed-by: Qt CI Bot <[email protected]> Reviewed-by: Mårten Nordheim <[email protected]>
* QML: Clean up sequence registrations for value typesUlf Hermann2022-02-111-12/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to be able to construct a meaningful list type by surrounding the internal name of the type with QList<>. Usually this works because of the way we auto-register sequential containers for types. Only for the builtins we need to do some special casing. That special casing should happen in the builtins, not in QtQml, though. The generic QList<foo> sequence type is implicitly given for any value type foo these days. There is no need to mention it in .qmltypes. QtQml retains some extra container declarations that are not straight QList<foo> for a value type foo. Everything that's registered by the value type registration anyway is dropped. We keep the aliases QStringList and QVariantList in the builtins because they are really common. Since we now register QVariantList the way it's mandated by the builtins, we also have to handle it correctly in qv4sequenceobject.cpp. In particular, we need to append variants as-is rather than poking into them. As QStringList is an additional builtin now, we need to teach the type resolver about it. Change-Id: I0dfb5b780b27250f36f6886bc4e0926a03c114b4 Reviewed-by: Andrei Golubev <[email protected]> Reviewed-by: Fabian Kosmale <[email protected]> Reviewed-by: Qt CI Bot <[email protected]>
* QML: Allow named lists of value typesUlf Hermann2022-01-281-35/+52
| | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
* SequenceObject: Define length accessors on the prototypeUlf Hermann2022-01-181-76/+71
| | | | | | | | Re-defining them for each single sequence object is quite expensive. Pick-to: 6.3 Change-Id: Ia7a602aada6f9904dd3a72ad5788482576170d9e Reviewed-by: Fabian Kosmale <[email protected]>
* Fix warnings when which are treated as errors with -developer-buildAssam Boudjelthia2021-10-041-5/+5
| | | | | | | | Pick-to: 6.2 Task-number: QTBUG-91163 Change-Id: I7fdac1ff11b4e1c5a6b0caa6cbeae67ddc3effc4 Reviewed-by: Qt CI Bot <[email protected]> Reviewed-by: Ulf Hermann <[email protected]>
* Add comments to use qsizetype for some APIs in Qt 7Assam Boudjelthia2021-10-041-0/+2
| | | | | | Task-number: QTBUG-91163 Change-Id: Iee52fce16d899a2a72277e314d7dc65b27da3b88 Reviewed-by: Ulf Hermann <[email protected]>
* Use QV4::Scope::hasException() where applicableUlf Hermann2021-06-301-1/+1
| | | | | | | It is shorter and encapsulates the exception handling a bit. Change-Id: I8e2dc0eb3b930e222b8cb4852b73d99ca18a0379 Reviewed-by: Fabian Kosmale <[email protected]>
* Pass QMetaType by value rather than by ID in more placesUlf Hermann2021-06-091-10/+8
| | | | | | | | | | 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 <[email protected]> Reviewed-by: Fabian Kosmale <[email protected]>
* QV4::Engine::toVariant: Use metatype instead of metatype idFabian Kosmale2021-03-251-2/+2
| | | | | | | | | | 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 <[email protected]> Reviewed-by: Andrei Golubev <[email protected]>
* Optimize ExecutionEngine::metaTypeToJS()Ulf Hermann2021-03-131-5/+10
| | | | | | | | | | | | | | | | 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 <[email protected]>
* QtQml: Integrate sequences with registration macrosUlf Hermann2020-11-111-33/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
* V4: Rewrite qv4sequenceobject based on QMetaSequenceUlf Hermann2020-10-021-336/+244
| | | | | | | | | | 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 <[email protected]>
* Rename QQmlQPointer to QV4QPointerUlf Hermann2020-09-211-1/+1
| | | | | | | You can wrap QObject pointers in plain JavaScript. Change-Id: I246a72a7d5d7b2562e722bf9eafc7880b772a806 Reviewed-by: Fabian Kosmale <[email protected]>
* Rename QQmlSequence to QV4SequenceUlf Hermann2020-09-211-68/+68
| | | | | | | This feature is available without QML, in pure JavaScript. Change-Id: Iec8a52ed10ed3eeaec24d3955c8c132bf2bd9677 Reviewed-by: Fabian Kosmale <[email protected]>
* Fix build after QStringList change in qtbaseVolker Hilsheimer2020-09-151-3/+0
| | | | | Change-Id: I258bcd59e7e97e025fa9ff77594bd8fdba0c34dd Reviewed-by: Lars Knoll <[email protected]>
* Check in even more places for exceptionsFabian Kosmale2020-04-211-0/+2
| | | | | | | | | Amends commit 4c5ed04e64ea9ac0038ae30e1189cfe745b29bd9 Task-number: QTBUG-83384 Pick-to: 5.15 5.12 Change-Id: I0918c27dfa73dff83cbf0f58b41ce8620dff8a0a Reviewed-by: Simon Hausmann <[email protected]>
* Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2020-01-151-1/+3
|\ | | | | | | Change-Id: I3058a6b9347d7ca2a0c04a58cb030ae5c47de415
| * SequenceObject: Better message when trying to write readonly containerUlf Hermann2020-01-091-1/+3
| | | | | | | | | | | | | | Before it would only output "Type Error". Change-Id: Ibd3a85f327c3ce8c58295c7e900c516b77c85a2b Reviewed-by: Fabian Kosmale <[email protected]>
* | Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2020-01-141-3/+0
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/imports/folderlistmodel/plugin.cpp src/imports/layouts/plugin.cpp src/imports/localstorage/plugin.cpp src/imports/models/plugin.cpp src/imports/particles/plugin.cpp src/imports/qtqml/plugin.cpp src/imports/qtquick2/plugin.cpp src/imports/shapes/plugin.cpp src/imports/statemachine/plugin.cpp src/imports/testlib/main.cpp src/imports/wavefrontmesh/plugin.cpp src/imports/window/plugin.cpp src/imports/workerscript/plugin.cpp src/qml/jsruntime/qv4sequenceobject.cpp src/qml/qml/qqmlengine.cpp src/qmlmodels/qqmlmodelsmodule.cpp src/qmlmodels/qqmlmodelsmodule_p.h src/qmlworkerscript/qqmlworkerscriptmodule.cpp src/qmlworkerscript/qqmlworkerscriptmodule_p.h src/quick/items/qquickitemsmodule.cpp Change-Id: I5f1fbc3d00e8f583d2c89afc5389de84d68633a7
| * qv4sequenceobject.cpp: Add "here be dragons" commentUlf Hermann2019-12-111-0/+16
| | | | | | | | | | | | | | | | No one should remove this at() before Qt6. Task-number: QTBUG-80535 Change-Id: I464c6f675dc68ad9762fcb594bb4d6ba6bdaf316 Reviewed-by: Fabian Kosmale <[email protected]>
* | qv4sequenceobject.cpp: Use operator[] rather than at()Ulf Hermann2019-12-091-1/+4
| | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
* | Fix build after QList->QVector changes in qtbaseLars Knoll2019-10-311-19/+1
|/ | | | | Change-Id: I1575c247de26ba08fba349bf879ed3e017530975 Reviewed-by: Simon Hausmann <[email protected]>
* Fix build without features.itemmodelTasuku Suzuki2019-07-081-4/+21
| | | | | Change-Id: Ia4304644a2a365c359eed31c55c2ca9d7d42f10c Reviewed-by: Ulf Hermann <[email protected]>
* Fix ownKey iteration over Proxy objectsLars Knoll2018-09-091-3/+4
| | | | | Change-Id: I045a4844c06df9232cc8b04485ab0a39bb990e3f Reviewed-by: Simon Hausmann <[email protected]>
* Implement ObjectIterator using the new iteration mechanismLars Knoll2018-08-021-25/+0
| | | | | | | And with that get rid of the old advanceIterator methods. Change-Id: I969fa89d25df8992a4b08c8c081b91c92ffdfddd Reviewed-by: Simon Hausmann <[email protected]>
* Introduce a new mechanism to iterate over object propertiesLars Knoll2018-08-021-0/+34
| | | | | | | | | | | | | | | | | 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 <[email protected]>
generated by cgit v1.2.3 (git 2.25.1) at 2025-05-04 14:46:24 +0000