This allows us to create value types with invokable copy ctors from
JavaScript objects that describe their properties. That way we now have
a full replacement for the Qt.foo() methods.
As a side effect, we support retrieval of enums for certain kinds of
broken value types now, if prefixed with a namespace.
Fixes: QTBUG-124634
Change-Id: If2a3c59d647e211ef5a0cd1ddee04b409d9ea5f3
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
We need to generate an exception if undefined is assigned to a property
that can't be reset. We don't want to reject everything that can
potentially be undefined. Therefore, we use the QVariant fallback and
examine the value for undefined at run time.
Pick-to: 6.7 6.6 6.5 6.2
Change-Id: I0a034032f4522f017b452690d93319eb4bfedb1c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The extra check for hasOwnProperty() was wrong. It was originally meant
for qmllint to find initial assignments to the same property but qmllint
has a different way of identifying those these days.
Amends commit d2507f2383.
Pick-to: 6.6 6.5
Fixes: QTBUG-118100
Change-Id: I6151b8088315b6a99e331b0830b9fdd8188a30cb
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Otherwise we get a conversion to unknown and that is bad.
Pick-to: 6.6 6.5
Fixes: QTBUG-117361
Change-Id: Iead1ddd21b692ed9fb9923dccdfa5bd01dc9d467
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Nicolas Fella <nicolas.fella@kdab.com>
This covers recursive write-back, but not write-back to members of
singletons or attached types, write-back of lists.
Task-number: QTBUG-116011
Change-Id: I6d33fae3bf9fdaed8d696a708124e0a707ecb07e
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
With this change, qmlcachegen can populate structured value types from
object literals.
Also fix the construction of value types via Q_INVOKABLE ctors. We don't
need to wrap the ctor argument in QVariant if we can store the original
type, and we should always look at the base type for the creatable flag,
not the extension.
Task-number: QTBUG-107469
Task-number: QTBUG-112485
Change-Id: I9f3db13f00466dc9d87237bdf0b380d6eeb58a10
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We may have implicitly invalidated it when shadow-checking.
Amends commit b3281f123e.
Change-Id: Ia5c54a3a0fa97c61e947ecb0a5b21d410e1bf19a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We should never store a list in a wrapper type that is itself a
different list. Wrapping and unwrapping requires rebuilding the list in
such cases. We can, however, store lists of builtins as-is. There is no
need to transform them. Other lists can still be stored in QVariant.
As a result, we now need to discern between the access semantics of the
stored type and the access semantics of the contained type. They are not
guaranteed to be the same anymore. Furthermore, we need to reject
"internal" manipulation of QVariant-wrapped lists for now. We might
implement them using QMetaSequence, though.
Task-number: QTBUG-113465
Change-Id: If09ea345b2fac39bf2abd62a2fce2d354df85b6b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It only worked for the console functions in 6.5. There it was suppressed
by the enforcement of type conversions in the basic blocks pass in dev.
We have, however, a good enough way to coerce QObject to QString these
days.
Task-number: QTBUG-112291
Change-Id: I025976cc7fbe430c5cdc607cae3ca48838b24f88
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We know that 'this' is a QObject* since the metatypes stack frame
mandates it. Whenever you pass 'this' to anything it's loaded from the
special 'This' stack slot which then triggers a DTZ check. A DTZ check
is a noop if we can prove that the type is statically known, though.
In QmlCompiler, if we have a valid register content, then the register
has been set in all code paths that lead to the instruction in question.
Fixes: QTBUG-111439
Change-Id: I81d1cd140eea63f85628c3bef3a8f6db0a12096d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
When checking for CallProperty we want the call base, not the
accumulator.
Pick-to: 6.5
Change-Id: I24ac066dd440bde459e20b3cf962af04ca531629
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
When reading a let or const register before its declaration we can be
sure this is invalid.
Task-number: QTBUG-108362
Fixes: QTBUG-77428
Change-Id: I7e8f8b46079860f00c051c1a91f773dc8cdd5595
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We don't discern between empty and undefined values in the compiler.
Fixes: QTBUG-104192
Change-Id: Ida06386433ef9e8f9a7cba4bec99ba8e77edc324
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
With a particular nefarious combination of Q_GADGET and inheritance from
QObject you can make QmlCompiler believe a type is a value type even
though it is actually an object type. We never want to touch such a
thing.
There was a safe guard against this when looking up the type from the
scope, but by putting it in a type namespace you could circumvent it.
Refactor the code to apply to both cases the same way.
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-104556
Fixes: QTBUG-105608
Change-Id: I8a690e2b6f78fcaba0911a93504cde0d2c7dde0d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We should not convert from undefined on storeNameSloppy. The reset is
intentional.
Task-number: QTBUG-104508
Change-Id: Iede88fe6331dd173c9e8ea0ec4200df2b8bd30eb
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
If the signal handler does nothing but return a closure, we have to
compile the closure using the same signature as the outer signal
handler.
In order for this to work, we also have to detect unresolved argument
types for signal handlers. Those are just as bad as unresolved argument
types for other functions.
Fixes: QTBUG-101531
Change-Id: Idb5b3994809d91a4b4ce936282685435eb75e670
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Those are generally less efficient than what the interpreter would do,
they can have side effects, and they can throw exceptions. We don't want
to deal with any of that. Most of those implicit conversions have
explicit equivalents. For those that don't we can add them.
Pick-to: 6.2 6.4
Fixes: QTBUG-104010
Change-Id: I62898db92219386c94f2a6c9b56f6fb0b7578832
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
When detecting an ambiguous type, we need to invalidate the entry in the
list of types, rather than delete it. If we delete it and we get yet
another version of the type, we'll add that one just like it was not
ambiguous.
Furthermore, we cannot check the type name when looking for ambiguity.
The QML name can be bent and twisted in various ways, to import
ambiguous-looking types under different names, so that they are actually
not ambiguous.
Pick-to: 6.2 6.3
Fixes: QTBUG-102153
Change-Id: Iee7951229c5f68b168899e55164e8cf91587eec1
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Previously we would not generate an error when an unknown function was
called.
Pick-to: 6.2 6.3
Change-Id: I31845a642afe0fd6038228c4aabf2ef5c6f1140e
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
If a type is not accessible in the imported version of a module, exclude
it. If we find multiple types for the same name and version, drop them
all and warn.
Pick-to: 6.2 6.3
Fixes: QTBUG-99113
Change-Id: I91d99d603ada6cf87f84afdbb01a543880d9aa76
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
qmlcachegen compiles bindings and functions to C++ as far as
QQmlJSAotCompiler can. It does respect "pragma Strict" and rejects the
file if it's violated. Furthermore, it sets up the logger to follow the
qt.qml.compiler.aot logging category. By default it's completely silent.
Compiling the examples with qmlcachegen exposes a bug in the type
resolver where it returns an invalid generic type. It should never do
that. Fix it by returning JSValue.
[ChangeLog][QtQml][Important Behavior Changes] QML bindings and
functions are now compiled to C++ by qmlcachegen, if possible. Use the
qt.qml.compiler.aot logging category to receive diagnostics about the
compilation.
Task-number: QTBUG-98305
Change-Id: I6953812c3fd20b68339617a5714fcbe16a384360
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Ulf Hermann
Maximilian Goldstein