Previously we'd allow access to internal types only based on URL. This doesn't work if the type is in a subdirectory. There we actually need to figure out if the type accessing the internal one is part of the same module. It might not be in the same directory after all. Pick-to: 6.12 6.11 Fixes: QTBUG-139770 Change-Id: Ic80a4db5663597a2be3e768ab1f4b488a397d50d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
In a multi-engine setup, different engines create different compilation units (and thus different QMetaObject instances) for the same composite type URL. The metaObjectForType() lookup queries the global type registry which may return a metaObject from a different engine's compilation unit. Since QMetaObject::inherits() compares pointer identity, instanceof would fail for objects whose metaObject doesn't match. Fix by using the engine's own QQmlTypeLoader to resolve the compilation unit, then getting the metaObject directly from its root property cache. This avoids the global type registry entirely for composite types and returns the correct engine-specific metaObject. Also, add a separate section for inline component types. We don't want to query the global type registry for those, either. Pick-to: 6.11 6.8 Fixes: QTBUG-146847 Change-Id: I372907bd5ee5199ebdd9d7e006c239bb9ad93b7b Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
The condition for fixing up the alias property index was wrong. Instead of checking the last list element, it was checking the first element twice. To avoid further mistakes and to make the logic easier to reason about, use std::find and std::distance to compute the index, and rely on the compiler to potentially optimize the loops. Amends 5b775e96c067995bf21cdf5a3641c50d5b7b272d Change compared to original commit: The logic is now in IRBuilder instead of in qqmltypecompiler. Fixes: QTBUG-144701 Change-Id: I589378b6cbc8d68f550ff7ec67be9a420ebee4d5 Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io> (cherry picked from commit 4f28b5469dd8e847abb54b6fa0dd75c6ae0e2874) Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
In QQmlVMEMetaObjectEndpoint::tryConnect(), the deep alias code path reads the intermediate object via QMetaObject::metacall(ReadProperty). If that intermediate object property hasn't been initialized yet (e.g. during object construction ordering), the ReadProperty call writes null into the target pointer. The subsequent connect() call then crashes trying to use the null target. Add a null check after the ReadProperty metacall and return early if the target resolved to null. This avoids the crash and leaves the endpoint unconnected (tag not set to EndPointIsConnected), so it can be retried on a subsequent notification. Pick-to: 6.11 6.8 Fixes: QTBUG-143361 Change-Id: I4d103cdf9d81e933afeb46c4b6a186ee4433cb35 Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
Aliases can point to IDs. You can't have bindings on plain IDs. Therefore, removing a binding from such an alias is a noop. Pick-to: 6.11 6.10 6.8 Fixes: QTBUG-124476 Change-Id: I6ac49bea025c9c5a72485130831cdbdbe0237ec3 Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
When we reorder aliases topologically, we need to also update the indexOfDefaultPropertyOrAlias, as that could otherwise point to the wrong alias. Amends 2dc11fd23c4607174878af6025b84ba5052650b8, which introduced the topological alias sort to fix a crash. Fixes: QTBUG-144701 Pick-to: 6.11 6.10 6.11.0 6.10.3 Change-Id: Icf733ca954ab346be9b94157a179a2c46439692d Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
resolveDeepAlias() previously only searched the target object's bindings and aliases to find the sub-property for a deep alias like 'alias foo: target.groupProp.innerProp'. This failed when 'groupProp' had no inline binding in the document. Fall back to looking up the sub-property on the declared type's property cache (via QQmlMetaType::propertyCacheForType) when no binding or alias match is found. Apply the same fix to the CompilationUnit specialization in qqmltypedata.cpp. Fixes: QTBUG-130605 Change-Id: I7f4d1c9af951c4059ce216f66d5f01d4c1757536 Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
We can have aliases of local aliases. In order to resolve those, we need to: 1. Look at aliases in addition to properties when trying to find the target. 2. Sort the aliases topoligically so that when we try to resolve an alias-to-alias its dependency has been resolved already. We have to append aliases to the property cache in the same order as they appear in the compilation unit. There is other code that depends on this. Amends commit 75dcbb156b2b1dfe0bb43e3119735f26f848e0f6. Amends commit 9e1378260a3f3a6eb4cad8d6ae47bc218e6a2b5f. Pick-to: 6.11 6.10 Fixes: QTBUG-144327 Change-Id: Ia8c0a1b060cd4247af20961d349d86e49dd0c895 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The same thing we need to do when checking assignability to singular types we also have to do when assigning to lists. Amends commit 4799905b81802f4a0acfeda353426e9f51d868c4. Pick-to: 6.11 6.10 6.8 Fixes: QTBUG-144092 Change-Id: I915b50d5671a6ca01ba381edc4c0c4d9b97cd970 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
If a required property cannot be set, abort the initialization of the object. Otherwise you end up with an object that's missing some of the properties you've explicitly marked as required. Also, accept extra properties in the object used to set required properties without warning. In JavaScript, having extra properties in objects, via prototypes or implicit properties created by the JavaScript runtime is the norm rather than the exception. [ChangeLog][QtQml][Important Behavior Changes] When instantiating an object from QML using Component.createObject() and some of its required properties cannot be set due to type mismatches, the object creation is aborted now. This is in line with what happens if a required property is missing altogether. Change-Id: I59347f871dd12813c6f0bd5e43eb294094c3d80f Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>