We need to assign them right away when creating the module. If we do it later on, there are a lot of different code paths to cover and in fact we were missing some. Pick-to: 6.8 Task-number: QTBUG-133053 Change-Id: I57e381c787f504eb9bcd8c2041e41b4f1d1f8b53 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> (cherry picked from commit c9778d2e9c41036cbd59976c51927d746bb78bcc)
The name of a bound function cannot be null. Amends commit 8b6a9403bf2e04d34b9b07d2780186029fab99d0 Change-Id: I8a32d4c2cc8170f1b5d722cd8c5b823aa2211975 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
These are really rather generic type traits that shouldn't be stored in individual objects. Moving them away slims down FunctionObject even more. FunctionObject doesn't add any extra overhead on top of Object anymore. You also cannot easily cast an object that doesn't implement any call methods to FunctionObject anymore. Therefore, we can derive from FunctionObject even if we only need to implement call methods in a further derived class. The fact that ProxyObject is not a FunctionObject but its derivatives are is already tested as part of the ecmascript test suite. Task-number: QTBUG-124662 Change-Id: I5632de8c54ac1d6a4b15c4926c655b87b475db49 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Most FunctionObjects do not actually need their custom jsCall members. They will only call the functions from the vtable anyway. FunctionObject can therefore be split into a static and a dynamic variant. Only the dyanmic variant needs to carry (and invoke) the extra pointer. The jsCallWithMetaTypes pointer is completely pointless because none of the dynamic functions actually implement it. Furthermore, the QV4::Function and QV4::ExecutionContext pointers in FunctionObject are only needed by actual JavaScript functions. The builtins that like to be dynamic functions never need them. Therefore, split out another class for this. In the generic FunctionObject, we need the capability to decide at run time whether the function shall be a constructor or not. Add a flag to replace the check for jsCallAsConstructor. Also, where we can, avoid the pessimization of checking whether a function is a constructor before trying to call it as constructor. Rather have the default implementation throw the exception. As a side effect, for most functions we don't need an ExecutionContext anymore. The engine is enough. Task-number: QTBUG-124662 Change-Id: Iac657fa71288dd6ec230a33de2986ba3bcf4628c Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Pass the metatypes of the contained types rather than the stored types. [ChangeLog][QtQml][Important Behavior Changes] The AOT compiled code for type-annotated JavaScript functions does not let you pass or return values of the wrong type anymore. Fixes: QTBUG-119885 Change-Id: I685d398c0745d32a999a3abd76c622a2c0d6651f Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Put the newly created FunctionObject into a Scope. This isn't actually needed, but acts as a safeguard in case FunctionObject::function is changed in the future to allocate memory. Change-Id: I5bcd888cd8bd5cb8c727eb3b29222981c851d4fe Reviewed-by: Sami Shalayel <sami.shalayel@qt.io> Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
You can produce multiple CUs for the same URL with createQmlObject() and friends. They need to be marked during garbage collection and therefore the engine needs to keep track of them. With the multihash there can be a lot of CUs of the same URL. Searching through them can take a lot of time. However, there is no point in searching for an existing executable CU if we've just freshly compiled the base CU. So, in those cases, insert directly instead. Fixes: QTBUG-121436 Change-Id: I804dbc74d2ade118f6680a7fbde3f234699ccbc3 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This is in preparation for letting the engine cache the executable CUs. Change-Id: Ideac10d8dda0784b41304b58f9b9fbd106173ea6 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We don't want floating unlinked executable CUs. They should always be tied to an engine, and the engine should not change. This gives us one definite point where to register them with the engine (to be done in subsequent change). Unfortunately, due to the refcounting, we need to remove the engine from any still-referenced CUs when the engine itself is destructed. We will be able to drop the refcounting and make the engine fully own its executable CUs once we can hold base CUs in most places. Change-Id: I9a53e83d5c4746c2b2bca896b51baa4fe7fee757 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We can use the same mechanism we have in place when calling typed JavaScript functions. The type coercion is generalized and moved to qv4jscall_p.h. We also use the correct JavaScript coercion in the rare fallback case where the types are actually different. Fixes: QTBUG-113258 Change-Id: I30404ee0122433b47227b2fc0dc4b0e3862a99c7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>