Details
-
Bug
-
Resolution: Unresolved
-
P2: Important
-
6.8
-
None
Description
Previously we made the assumption that an alias to a required property would itself be required. This is wrong and should be fixed by https://codereview.qt-project.org/c/qt/qtdeclarative/+/605135/.
Earlier, https://codereview.qt-project.org/c/qt/qtdeclarative/+/551055 added a mechanism to enforce that required properties be set explicitly by the user instead of being silently default initialized / not initialized. Failure to set these would result in a compile error at the Cpp level. It had some of the same assumptions regarding aliases to required properties. Because qmltc relied on the top-level properties aliasing the (inner) required ones to be required as well, its enforcement for required properties is partially broken and it will sometimes not fail to compile when required properties are not set.
Here, qmltc used to demand that ai be set explicitly. Now, since ai is no longer required, qmltc will not check whether i is actually set anywhere or not.
Item { property alias ai: inner.i Item { id: inner required property int i } }
The above example should be relatively easy to fix by still requiring ai to be set as it is the only way satisfy i, but the following example shows that a more complex solution is required.
Item { property alias ai1: inner.i property alias ai2: inner.i Item { id: inner required property int i } }
Here, in order to satisfy i, either ai1 or ai2 needs to be set (what happens when both are set?). The RequiredPropertiesBundle mechanism will need to be adapted to cope with these multiple possible legal creations of the type.