QNX by default has smaller stacks than other platforms.
Pick-to: 5.15 6.2 6.3
Change-Id: Ia83d4e12c0fd24c51069777db2283d456c49800f
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Pasi Petäjäjärvi <pasi.petajajarvi@qt.io>
QML sequences are required for named lists of value types. The original
reason for the introduction of this feature was the template code
explosion caused by the way the sequence types were registered in Qt5.
As we register them differently now, the code size overhead should be
smaller. It makes very little sense to switch sequence types off these
days.
[ChangeLog][QtQml][Important Behavior Changes] The qml_sequence_object
feature flag has been removed. Omitting sequences from the QML language
does not make much sense now that we use them for lists of value types.
The original reason to allow it was that the sequence support took up a
lot of space in the binary. This is not the case anymore since 6.0.
Change-Id: I2f1d43cdd29ba63853316b06113cb49ed30aa410
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We can convert everything into a QJSValue if we have an engine and we
can save a binding function in a QVariant by wrapping it into QJSValue.
Change-Id: I48e7c13f3f744f1c50bf673b427fe9331250f313
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This turns out to be not quite valid since context hierarchy is
afffected. It was fine before since all the generated classes either
had the same context or a dead-simple hierarchy + the tests for
comprehensive usage were lacking. The problems arise when contexts are
meant to be different for unrelated JS calls e.g. in property bindings
with non-trivial cross-context dependencies (e.g. derived property
uses both neighbor property and base class property in a binding)
As a drive by, simplify QQmlEnginePrivate::executeRuntimeFunction():
* Expect function index to always be valid (in range), it's a very bad
otherwise anyway
* Use QQmlData::outerContext directly as a context argument for
callInContext(). This is what was done anyhow, just through a
QQmlContext -> QQmlContextData conversion, which is actually needless
Change-Id: I8ac6b181363a5d03e468c2b6f35db2dac188ea8b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
We should pass the variants themselves, not their constData().
Fixes: QTBUG-94502
Pick-to: 6.1 6.2
Change-Id: I92688348d7b46d74935dc11080b26290f5e8be86
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
If we call an AOT-compiled function we never need the JavaScript call
frame. We can just skip its setup and save some overhead.
Change-Id: I39dc2ca6eea5b5a66f3b87b642a310534cecf6cd
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This saves us some ping-pong between the IDs and the QMetaTypes, and
avoids possible ambiguities if multiple metatypes are registered for the
same C++ type.
Change-Id: I81cec94a9cd05d69927dc884f65574f0ab2ddc22
Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It really only works for value types and it's not intended to do
anythign else. The name should reflect this.
Change-Id: Ib73bf7e9655971f7826fe72145e2d2fab363363c
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We implicitly do the same when calling toVariant().
Change-Id: I288326125d88bc658dcaf12d3ee623e0e529bb69
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Due to the quirk of ECMAScript's Date.parse() spec [0] stipulating the
use of UTC for date-only strings, in contrast to most other ways of
creating a Date using local time, reasonable users get surprised by
the behavior of QDate properties initialized from strings. This can't
be avoided without breaking other uses of Date, so document the
work-around needed to cope with it (use UTC-specific methods to access
the Date object).
[0] https://tc39.es/ecma262/#sec-date.parse
Make conversions back to QDate from Date work round the possibility
that the Date, seen as a QDateTime(,, LocalTime), needs to be handled
as UTC when extracting the date, and catch two more places that
conversion from QDate neglected to use UTC's start of day, for
consistency.
Revised tests to call UTC-specific methods instead of the local-time
ones, where appropriate. Drive-by: some tests were (entirely bogusly)
constructing a fresh Date using the UTC-fields of the Date they had,
in order to then test the non-UTC fields of this fresh Date; instead,
simply test that the UTC fields are as expected.
[ChangeLog][QML][Behavior change] Where a QDate is represented in
QML's JavaScript as a Date, it is now more consistently associated
with the start of the UTC day it describes. Previously cases where it
was represented as the start of local time's day could lead to a Date
turning into a QDate for the preceding day. Inconsistencies in the
specified behavior of Date preclude eliminating such problems
entirely, but they should now be limited to cases where (perversely
for a date property or parameter) the date is specified with a local
time late enough to make it coincide with the start of the next UTC
day (in which case that next day's QDate will be its C++
representation).
Fixes: QTBUG-92466
Change-Id: I2306dd9ecef0d5c2d59b562762392e51bb6d66ca
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Use the newer version of QV4::Function::call() that does not require
manual JSCallData setup and is more optimal for AOT function calls
Change-Id: I5a5e2d0477c0603b05b7213f1b2adcc34d156bf5
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Previously passing a QList of a registered enum would result in an array of objects instead of the array of numbers which usually represent enum values in QML.
You now get an array of numbers as you would expect.
[ChangeLog][QtQml][Important Behavior Changes] QJSEngine::toScriptValue() used to return a QVariant containing an enum, now it returns the enum directly. If you still wish to use valueOf() on the resulting value use QJSEngine::toManagedValue() instead.
[ChangeLog][QtQml][Important Behavior Changes] A QList containing enums will now result in an array of numbers instead of an array of objects.
Fixes: QTBUG-85861
Change-Id: I5c28f4489dfd02d8256aa818e27b1dd6b7d3113d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Some applications that use JavaScript as a scripting language may want
to extend JS through C++ code. The current way to do that is with
global objects.
ES6 provides a better way of encapsulating code: modules.
registerModule() allows an application to provide a QJSValue as a named module.
Developers familiar with Node.js will find this very easy to use.
Example:
```c++
QJSValue num(666);
myEngine.registerModule("themarkofthebeast", num);
```
```js
import badnews from "themarkofthebeast";
```
[ChangeLog][QtQml][QJSEngine] Adds the ability to register QJSValues in
C++ as modules for importing in MJS files.
Change-Id: I0c98dcb746aa2aa15aa2ab3082129d106413a23b
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
URL has become a builtin type. We should support it on the same level as
QString/String and QDateTime/Date.
In order to continue support for comparing URL properties with the
JavaScript equality operators, we still pass URLs as variants when
using them in JavaScript. However, we now create proper URL objects for
QJSValue and QJSManagedValue, and we allow transforming the URL-carrying
variant objects back into QUrls.
Change-Id: I78cb2d7d51ac720877217d2d4b4d0ab17cdd2a4b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This way, we can avoid the costly id to metatype lookup in case where we
actually need the full metatype.
Task-number: QTBUG-88766
Change-Id: Ibe29b323007f00d2f8d1807fb9b64f9a8f87e807
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
This is pretty much the same as creating them from QQmlListReference.
Change-Id: I8d873840fc08887655d19a61b028f3eb60eaf938
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
In the good case this is just reading a few members of the relevant
classes. No need to call functions for this.
Change-Id: I9908cd6437cf9a1ca840f9aa0e524d3976272d67
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We should avoid looking up metatypes by ID. That's expensive.
Change-Id: I00ce0a7f95ec82b0db6e7eb976e39e50522a7fe4
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
We need to be able to retrieve QQmlListReference and attached objects
from QJSValues.
Change-Id: I39679317da4066b054e86f767fc5f723ead2b2e7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Parsing the type from a signature is expensive and we can do better in
most cases.
Change-Id: Iae85f4dec9ad6b8de60efeb3469a253fd0862672
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
When called via the metaobject system, parameters and return values are
passed as void*, with accompanying type information in the form of
QMetaType. The same format is expected when calling an AOT
compiled function.
Previously, we would first convert all the parameters to QV4::Value,
just to convert them back the moment we notice that there is an AOT
compiled function. This is wasteful.
This change provides a second call infrastructure that accepts void* and
QMetaType as parameter and return value format, and passes them as-is
all the way to any AOT compiled functions. If there is no AOT compiled
function, the conversion is done when detecting this, rather than when
initiating the call. This also passes the information "ignore return
value" all the way down to the actual function call. If the caller is
not interested in the return value, we don't have to marshal it back at
all.
For now, we only add the extra "callWithMetaTypes" vtable entry to
ArrowFunction. However, other callables could also receive variants
optimized for calling with void*/int rather than V4 values.
This required changing the way how function arguments are stored in the
property cache. We squeeze the return type into
QQmlPropertyCacheMethodArguments now, and we use QMetaType instead of
integers. In turn, we remove some unused bits.
Change-Id: I946e603e623d9d985c54d3a15f6f4b7c7b7d8c60
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We either have pre-populated arguments and thisObject, then we can just
use them and keep them const. Or, we want to allocate and populate the
arguments and the thisObject. Then, do allocate them in a separate
object, and transform that into JSCallData afterwards if necessary.
Furthermore, avoid alloc(0) as that just returns the current stack top.
Writing to it will clobber other data. Rather, just use nullptr and
crash if it's written to.
Also, remove the useless operator-> from JSCallData. That one just
confuses the reader.
Change-Id: I8310911fcfe005b05a07b78fcb3791d991a0c2ce
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We only need it when generating CallData, or when filling in any
thisObject or arguments that weren't provided. Provide a constructor
that expects thisObject and arguments to be pre-allocated and one that
allocates them in a scope passed as argument.
Change-Id: Iddfba63f4dbc5b09e2b33fb22a94eea88f515902
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
We can cache the QQmlContextWrapper rather than retrieving it twice.
Inline some things, and do not unnecessarily create and destroy ref
pointers.
Change-Id: Ife0980f83b7efe1ea9dc56aacbfbccd029ce77c8
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We almost never need to construct a QVariant to do this. Constructing a
QVariant is excessively expensive if you have something simple like an
integer. This also fixes the unexpected "unwrapping" of variants when we
pass them through QJSValue.
[ChangeLog][QtQml][Important Behavior Changes] If you create a QJSValue
from a nested QVariant (that is, a QVariant containing another
QVariant), then, when retrieving its contents again, the outer variant
is not unwrapped anymore. Rather, you get exactly the value you've
passed in.
Change-Id: I8c16eed4f13e8cfdeced0756eef593b3b8e84dd1
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We already covered the case where the metatype's flag indicate that it
is a QObject. That is exactly the same check used in
QQmlMetaType::toQObject, so if the test did not succeed before, it won't
succeed now either.
As a drive-by, avoid useless metatype-id to metatype lookup.
Change-Id: Ie36a07587aa2b899d2a932bcb3f4a0b5da8aa282
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Instead of arguments around as a pointer to
[argc, metaTypeId1, metaTypeId12, ...]
pass argc and a pointer to [QMetaType1, QMetaType2] around.
Moreover, make use of the fact that we now carry the metatype instead of
only the id in a few places, to avoid id -> metatype lookups.
Task-number: QTBUG-82931
Change-Id: Ib00e4d793727f85f3358a8162d1aac972daab3d3
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
[ChangeLog][QML][Important Behavior Changes] If a QObject pointer is
passed to the QML engine and subsequently frozen with Object.freeze,
modifying its QObject properties now fails and throws a TypeError. The
TypeError is thrown even in non-strict mode.
[ChangeLog][QML] It is now possible to pass const QObject derived
pointers to QML in properties, and to call Q_INVOKABLE functions which
take such pointers as arguments. If the QML engine receives such a
pointer, it is treated as if the object was frozen.
Fixes: QTBUG-82354
Change-Id: Ib0dbcdfb2370654505936c3cf391d87dd2c9677b
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
It appears that nowadays v4->metaTypeToJS handles QVariant and QObject
derived classes just fine, and in exactly the same way as the custom
code in populateJSCallArguments did.
Task-number: QTBUG-82931
Change-Id: Ic5f97dfc3296a409fdd6a1fcb78d3b9bdba5f3a1
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
You can also cast enums to integers, after all.
Pick-to: 6.1
Change-Id: I283d3dd280eeb44ba22bb45ca9be69e5358d5781
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Add execution function that can evaluate runtime functions available
in the compilation unit. Private API for now as it's unclear what would
be a comprehensive solution to support all existing use cases
Task-number: QTBUG-84368
Task-number: QTBUG-91039
Change-Id: Icf755b53484587d7983eaae4821c1aa0111d5c05
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Move the value type registry into QQmlMetaTypeData. This way we can
conveniently drop the relevant entries when unregistering a type.
Fixes: QTBUG-86946
Change-Id: Id024a34a8b2b622fd9417fc0e52864b43c66cc01
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Previously it would only disable loading of separate cache files.
Change-Id: Iae92fc03d2e5566ef7dc44a6730b788b7512fd3d
Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This time, the ValueTypeFactory gets converted. As a consequence, many
callers get touched again.
Task-number: QTBUG-88766
Change-Id: I3a8b7d5cfeb7fac85daf1702febba205971d4256
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Also, allow conversion from UrlObject and String. We allow the string
conversion because we treat string and url as interchangeable in various
places.
Change-Id: Ib229c6d190e1c5d849ea18798925965b8dbeef7e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This is a single char16_t, not an array of them.
Pick-to: 5.15
Change-Id: I55d23ebb5f2abebd43cd4160a75d373706392ddf
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
You get to write QML_SEQUENTIAL_CONTAINER(value_type) now, and
qmltyperegistrar will generate a sensible registration call from that.
A registration might look like this:
struct MyStringListForeign
{
Q_GADGET
QML_ANONYMOUS
QML_SEQUENTIAL_CONTAINER(QString)
QML_FOREIGN(MyStringList)
QML_ADDED_IN_VERSION(3, 1)
};
It's unfortunate that we need to use a metaobject to transfer all of
this information, but there is no other sensible way.
Transform the containers defined in qv4sequenceobject.cpp to use the new
style, and move them out of the builtins, into QtQml. Recognize that
only one of them was ever tested, and add tests for the rest.
Task-number: QTBUG-82443
Change-Id: I3a30f9e27266bb575eea26c5daf5dad1ec461cc5
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Quite obviously, the Qt object is a singleton, extended with a
namespace, backed by a member of the JavaScript global object.
Defining all the methods as JavaScript functions is unnecessary and
duplicates the general type transformation code. Also, it makes it
hard to use those same methods from a C++ context as we cannot
properly set up the arguments outside the JS engine.
Rewriting the Qt object reveals some deficiencies in the old
implementation that we need to fix now:
1. The enums of the Qt type were listed as properties of the Qt object,
which means you could iterate them with a for..in loop in in JavaScript.
This is just wrong. Enums are not properties. This functionality
is deleted and the test adapted to check for each enum value separately.
The commit message for the change that introduced the iterability
already mentioned that the author had failed to find any occurrence of
this in the real world.
2. Parsing time objects from strings was done by parsing the string as a
date/time and then picking the time from that. We still support that for
now, but output a (categorized) warning. Parsing the time directly is
preferred where possible.
3. Previously you could create (invalid) dates and times from various
kinds of QML types, like int and color. This does not work anymore as we
now validate the types before calling the functions.
4. Passing more arguments to a function than the function accepted was
unconditionally ignored before. Now, a Q_CLASSINFO on the surrounding
class can specify that the arguments should be checked, in which case a
JavaScript error is thrown if too many arguments are passed. In order
for this to work correctly we also have to ignore JS undefined values as
trailing arguments for overload resolution. This way, if a method
matching the defined arguments exists, it will be preferred over a
method that matches the full argument count, but possibly cannot accept
undefined as parameter.
Consequently a number of error messages change, which is reflected in
the qqmlqt test.
[ChangeLog][QtQMl][Important Behavior Changes] You can not iterate the
enumerations of the Qt object in JavaScript anymore. This does not work
with any other enumeration type either. You can of course still access
them by name, for example as Qt.LeftButton or similar.
[ChangeLog][QtQMl][Important Behavior Changes] The time formatting
functions of the Qt object in QML now allow you to pass an actual time
string, rather than a date/time string as argument. Passing a date/time
string results in a warning now.
[ChangeLog][QtQml][Important Behavior Changes] Functions in the Qt
object for formatting date and time will now throw a JavaScript error
when presented with a value of an incompatible type, such as int or
color.
[ChangeLog][QtQml][Important Behavior Changes] The Qt.resolvedUrl()
function now returns a URL rather than a string. This follows the
documentation.
[ChangeLog][QtQml][Important Behavior Changes] The GlobalColor enum of
the Qt namespace is not exposed to QML anymore. It did not make any
sense before as the enum values could not be used as colors.
Change-Id: I7fc2f24377eb2fde8f63a1ffac5548d652de7b12
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This avoids the template explosion and makes the mechanism extendable.
You can now register additional anonymous sequential containers.
Fixes: QTBUG-71574
Task-number: QTBUG-82443
Change-Id: I5b9ed9af1533a3b7df8fc5bb37bbb73b8304e592
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
metaSequence() became metaContainer() and we should ask for canConvert()
as there are two ways to convert to a container.
Change-Id: Iba868491ff9d2cc8fc89de1cab29818b834b53f4
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Due to qiterable.h specializing a template declared in qmetatype.h we
temporarily need to include it in a few tests so that the iterables
work.
Change-Id: Ia32392419dead76eaf2b91b2ec4157b726d8de74
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
When converting a QDate to a QDateTime, startOfDay() takes care of
avoiding any gaps in time at the start of the day, where naively
asking for QTime(0, 0, 0) can produce an invalid date-time.
Change-Id: I24f3d230eb1ee7396600b030ad1305e060215cbd
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
They're value types, packaging qint64 and int respectively.
Change-Id: I78a0097f77238751ac3ef9f928537f719a6d05d6
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The internal QVariant constructor taking a QMetaTypeId has been removed.
Thus, construct QMetaTypes where necessary from the id, or avoid a
QMetaType -> ID -> QMetaType roundtrip where we already have a metatype.
Also fix a few missing includse that were previously transitively
included.
Change-Id: I56ce92281d616108a4ff80fe5052b919d1282357
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@qt.io>
Ulf Hermann
Andrei Golubev
Edward Welbourne
Maximilian Goldstein
Alex Shaw
Fabian Kosmale
Lars Knoll