Define a pair of lookup methods for this and generate code that uses
them. Write back after calling a non-const method.
Task-number: QTBUG-127174
Change-Id: I6de22e76b63390fd7159d9c14ea2c908d961ec97
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
With SetLookup there is always the possibility of causing a reset by
passing undefined. That's why we need to wrap the argument into QVariant
most of the time. SetValueLookup didn't take this into account, which
resulted in invalid code.
The test also reveals that a number of cases were generating different
errors depending on whether the code was run in interpreted or compiled
mode. Align those.
Pick-to: 6.8
Task-number: QTBUG-127174
Change-Id: I88f45977dcd0eeba8aaf580663d4b85b8bb26f72
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
On the engine side, types made available with QML_USING are recognizable
by their QMetaType conversions. In order to actually call the right
methods, we need to slightly prefer methods to whose arguments we can
convert over ones we have not idea about. This, however, adds the
problem of converting to QString, double, QVariant and QJSValue, which
is possible for any type. Since such conversions are less specific than
manually added converters, we de-prioritize them a bit.
On the compiler side we need to transmit the knowledge about the
overload to be called from the compiler (which has already done its own
overload selection) to the lookup methods. This is easily done using the
relative method index. This way we do not need to do any run time
overload selection at all and we do not need to pass any types to the
lookup methods. We can do this without further compatibility adaptations
because the current version of those lookup methods was only introduced
in 6.9.
Excluded, of course, are shadowable calls, which are performed with only
QVariant arguments. These carry the arguments themselves and trigger the
engine's overload selection. Internally nothing changes about them.
Passing a list of QMetaType::fromType<QVariant>() to the lookup methods
for them has always been a waste.
Only the engine changes are relevant for 6.8. In 6.8, the lookup methods
defer the overload selection to the engine and take the types on every
call. We still cannot separate the engine changes from the compiler
changes in dev because the same test is run once in interpreted and once
in compiled mode.
Pick-to: 6.8
Task-number: QTBUG-127174
Change-Id: I6ab52ddf3be65dcc94547266c5dcc5ac1050c93c
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
qmlcachegen will never generate code that calls these with mismatched
types. Checking the type at run time is wasteful. With QML_USING, you
can make qmlcachegen generate code with types we cannot recognize as
compatible. However, those need to be layout-compatible so that they
can be reinterpret_cast'ed into each other. If they aren't that's a user
error in C++. We can crash on such a thing.
However, in StoreNameSloppy and in the variant lookup cases, we do need
to convert types. Since the QML_USING type conversions are unknown to
the QML engine, we have to provide a fallback via QMetaType::convert()
here. So, despite the layout compatibility requirement, the QML_USING
types also need to register metatype converters before any QML code
accesses them.
As a result QML_USING has quite a few complicated requirements now and
is _really_ dangerous.
Pick-to: 6.8
Task-number: QTBUG-127174
Change-Id: I1b8e1595e3088415ce711e910586a5dd456cb2c5
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
Ulf Hermann