aboutsummaryrefslogtreecommitdiffstats
path: root/src/qml/jsruntime/qv4qmlcontext.cpp
Commit message (Collapse)AuthorAgeFilesLines
* QtQml: Try harder to find a propertyCache for destroy() and toString()Ulf Hermann2025-11-071-4/+4
| | | | | | | | | | | | | Those are conceptually part of the QObject property cache, even though they have no property data. So, if the object at hand does not have a property cache of itself (e.g. because its fully dynamic), look up the QObject one and use that. Fixes: QTBUG-141704 Pick-to: 6.10 6.8 6.5 Change-Id: Ia333ac8c29f3797fb4b3ff37863b7c01fae8b076 Reviewed-by: Sami Shalayel <sami.shalayel@qt.io> Reviewed-by: Joshua GPBeta <studiocghibli@gmail.com>
* CRA review qml/jsruntimeFabian Kosmale2025-09-161-0/+1
| | | | | | | | | | | | | | | | | | This relies heavily on the documented fact that we only support trusted QML/JS content, meaning most files are only significant, not critical. This also extends to the handling of qmlc files (as in compilationunitmapper), as we store them in a user owned, non-shared cache directory – so any vulnerability there would already mean that an attacker has write-priviledges on user data. An exception is ArrayBuffer, which can be used with arbitrary user data, and should create a valid QBA. Fixes: QTBUG-136970 Pick-to: 6.10 6.9 6.8 QUIP: 23 Change-Id: I22033fe6ab4acf8362a8183e25b92331d45cb32c Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QtQml: Fix leftovers from V8Ulf Hermann2025-07-111-1/+1
| | | | | | | Some comments and header guards still had V8 in them. Change-Id: I71e888fb72916fcd948a293d9fd50fb54a9499c3 Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
* QtQml: Hold QQmlTypeLoader in QV4::ExecutionEngineUlf Hermann2025-06-171-1/+1
| | | | | | | | | | | ... rather than QQmlEngine. This paves the way for having the type loader attached to ExecutionEngine rather than QQmlEngine. Also, reference the execution engine in the type loader, in turn. Task-number: QTBUG-19407 Change-Id: I04e571c5c6ac5bce5e82537cb96c6940c7186f3a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* fix typo: QSrtingFrederik Gladhorn2025-04-131-2/+3
| | | | | | | Also make clang-format happy with the comment. Change-Id: Ia38a103dcfe01bace097ea6290bdf65494fc9282 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QtQml: Fix AOT compiled context for destroy() and toString() methodsUlf Hermann2025-02-261-24/+22
| | | | | | | | | | | | | | | | | | | | Those are not mapped to regular QMetaMethods but rather come with special method indices and need to be resolved separately. Amends commit a741271dd58b21728928684f1ef1efaa91e79ebf This exposes that the override order between JavaScript extensions and their base types was wrong. JavaScript extensions do certainly not override their base types. Fix this, too. We also need to always specialize the lookups for these calls. It doesn't actually matter if there is propertyData or not since we branch off into the special cases anyway when calling them. Pick-to: 6.9 Fixes: QTBUG-132602 Change-Id: Iea83ce94459b0d0a3bf54731898fd62b9ad46c46 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QQmlContextData: Don't expose PersistentValue in imported scripts APIFabian Kosmale2024-11-011-2/+2
| | | | | | | | | This is in preparation of the next commit, which will change how we store the data internally. Pick-to: 6.8 Change-Id: I5b35639c8757770c1efad98f85c70227344adeea Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QtQml: Call lookups based on enums rather than via function pointersUlf Hermann2024-10-241-36/+35
| | | | | | | | | | | | | | | | | While the C++ standard says that different functions need to have unique addresses, some compilers have take substantial liberties with that rule. This means we can't actually rely on the addresses of our different lookup functions to differ and therefore we cannot use them as discriminator. Introduce an enumeration for all the different lookups and use that instead. Now we can also drop all the purely redirecting methods we've introduced just to have different addresses. Change-Id: Ifa68c27c0d2fef4084893a19227dab21bd948dfd Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QtQml: Straighten out some logging categoriesUlf Hermann2024-06-171-1/+1
| | | | | | | | | | | Either make them static or declare them in a header. We want them to be static wherever possible, in order to reduce the number of visible symbols. If they can't be static, however, they should at least be declared in only one place. Task-number: QTBUG-67692 Change-Id: I91fa641b46510ea8902b478d31dfd60d34b5f580 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Prepare for white allocations during gc (1/9): Write barrier for LookupsFabian Kosmale2024-03-051-5/+5
| | | | | | | | | | | | | | | | | | | | | | | 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>
* QtQml: Remove QQmlTypeLoader from QQmlImportUlf Hermann2024-01-111-2/+3
| | | | | | | | | 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>
* QML: Let IDs in outer context override bound components' propertiesUlf Hermann2023-12-041-2/+26
| | | | | | | | | | | | | | | | | | 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>
* resolveQmlContextPropertyLookupGetter: Use ScopedPropertyKeyFabian Kosmale2023-11-151-4/+4
| | | | | | | | | | 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>
* Move ScopedStackFrame into qv4stackframe_p.hUlf Hermann2023-05-171-0/+1
| | | | | | | | | | | 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>
* QML: Allow as-casting to value typesUlf Hermann2023-03-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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>
* Recursively write back value types and sequencesUlf Hermann2022-10-191-7/+12
| | | | | | | | | | | | | | | | | 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>
* QML: Optimize QObject method callsUlf Hermann2022-09-201-35/+121
| | | | | | | | | | | | | | | | | | | | | | 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>
* Fix precedence between JS and QML scopesUlf Hermann2022-07-251-18/+28
| | | | | | | | | | | | | | | | | 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>
* 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 <shawn.rutledge@qt.io>
* Respect invokable toString() methodsUlf Hermann2022-03-281-7/+11
| | | | | | | | | | | | | | | 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>
* QmlCompiler: Fix a number of warts regarding type lookupUlf Hermann2022-03-231-2/+2
| | | | | | | | | | | 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>
* Make most QQmlPropertyData constUlf Hermann2022-03-141-2/+2
| | | | | | | You really should not mess with that after creating the property cache. Change-Id: I070200772475bb67f539dbbd85a298020b14ca79 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QML: Handle dynamic meta objects in AOT lookupsUlf Hermann2022-03-031-0/+5
| | | | | | | | | | | | 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>
* Revert accidental change in qv4qmlcontext.cppUlf Hermann2021-12-121-2/+1
| | | | | | | | | | | 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>
* V4 Lookup: Do not leak property cachesUlf Hermann2021-12-091-12/+7
| | | | | | | | | | | | | | | | | | | | | | 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>
* QQmlTypeNameCache: Unify querying for typesUlf Hermann2021-12-031-1/+1
| | | | | | | | | | | | | | | 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>
* Clean up PropertyCache life cycleUlf Hermann2021-11-091-2/+2
| | | | | | | | | | | | | 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>
* Clean up some includesUlf Hermann2021-11-051-13/+13
| | | | | | | | | 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>
* Avoid QAbstractDynamicMetaObject where possibleUlf Hermann2021-10-121-1/+4
| | | | | | | | | | | | | | | | | | | | | 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>
* Use custom lookup for QJSValue singletonFabian Kosmale2021-05-051-3/+12
| | | | | | | | 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>
* Remove caching of recursive AOT context lookupsUlf Hermann2021-04-301-0/+6
| | | | | | | | | 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>
* Streamline retrieval of context property names and IDsUlf Hermann2021-04-151-13/+5
| | | | | | | | 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>
* QQmlMetaType: Remove qmlLists memberFabian Kosmale2021-03-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix QJSValue singletons only supporting object typesMaximilian Goldstein2021-02-221-6/+17
| | | | | | | | | | 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>
* QML: Warn about usage of injected signal parametersUlf Hermann2021-02-121-3/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* qv4qmlcontext: Fix bounded signal expressions when debuggingMaximilian Goldstein2020-12-041-2/+2
| | | | | | | Fixes: QTBUG-83599 Pick-to: 5.15 Change-Id: I8909f0b2d3eca909512b99c172c8dc5e93e48482 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Add ; to Q_UNUSED and UNUSED_PARAMLars Schmertmann2020-06-261-4/+4
| | | | | | | | | 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>
* Encapsulate QQmlContextDataUlf Hermann2020-03-231-52/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Store a QV4::ReturnedValue in QJSValueUlf Hermann2020-03-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Implement lookups for qml type wrappersSimon Hausmann2019-09-051-3/+28
| | | | | | | Task-number: QTBUG-77237 Change-Id: I661dc7a23946520c8ad298c39796cb8d0561d80c Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Merge remote-tracking branch 'origin/5.13' into devQt Forward Merge Bot2019-07-011-2/+8
|\ | | | | | | | | | | | | | | Conflicts: src/imports/imports.pro src/qml/qml/qqmlmetatype.cpp Change-Id: I308436caf55402cb2246cb591c6ac8f83e1febf8
| * Fix thisObject when calling scope and context properties through lookupsUlf Hermann2019-06-261-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/5.13' into devQt Forward Merge Bot2019-06-111-2/+0
|\| | | | | | | | | | | | | | | | | | | 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
| * Fix lookups of properties in QML singletonsSimon Hausmann2019-05-211-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/5.13' into devQt Forward Merge Bot2019-05-021-5/+11
|\| | | | | | | Change-Id: I5d2c3da38df35922b2147c3c0bc55c6c3bae2fe5
| * Skip block context within call contexts when searching for parametersUlf Hermann2019-04-291-5/+11
| | | | | | | | | | | | | | | | | | | | | | 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>
* | Move creation and management of singletons to QQmlEnginePrivateRichard Weickelt2019-04-241-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Remove unused includes of qv8engine_p.hUlf Hermann2019-04-091-1/+0
|/ | | | | Change-Id: Ic135a863581d29a3afb9c6c7f070d2630b3913b4 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Enable lookups for imported scripts and worker scriptsSimon Hausmann2019-03-251-3/+16
| | | | | | | | | | | | | 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>
* Accelerate lookups of properties in outer QML contextsSimon Hausmann2019-03-211-52/+113
| | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-01 23:03:51 +0000