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>
When converting JS arrays to sequence<T> type, check first for the
existence of a QJSValue -> T converter function. This restores the
behavior from Qt <= 5.14. Amends ecdb4ed275
Fixes: QTBUG-84104
Change-Id: I14c86ab37e34a3c8cff072574d4b90fe9e558535
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Now that char16_t is used in Qt (for instance in QChar::unicode()), we
need to support it.
Change-Id: I527a70795524bfd883fc4d729aac714708b51181
Reviewed-by: Liang Qi <liang.qi@qt.io>
Implements URLSearchParams (https://url.spec.whatwg.org/#urlsearchparams),
completing our implementation of the URL object.
Still needs the for..of iterator to get implemented.
Change-Id: Iad33ed2f3fe0b2598ca2b0b21a4743f5f7dc19fd
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Use the unused field in the CachedUnit structure provided by qmlcachegen
to allow for providing function pointers for functions and bindings that
are compiled ahead of time.
Provided is the pointer into an array that is terminated with a {index:
0, functionPtr: nullptr} entry. The array index field in each array
entry allows for gaps.
Change-Id: I7457f5eea5f14e5f94431b9cc6da042cb03517a0
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Pass the address of the entire structure through to the compiler, so
that when adding new members we can easily access them.
Change-Id: I5da75ba4e64d3e0e750a3ff3df4edbb88cdb6937
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Implements the JavaScript URL object (https://url.spec.whatwg.org/#api).
Except that it does not currently implement the searchParams field.
Task-number: QTBUG-54988
Change-Id: I19abc69e075cbf84bd15e6791be195ce16f3fe73
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Remove all code that supported converting between JS RegExp's and
QRegExp, as QRegExp is going away in Qt6.
Change-Id: I4863e68dd87a337d7e836d1b26c28ee3bb914e9f
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Also, fix the check to actually test the correct capabilities by using
the containerCapabilities function; testing _iteratorCapabilities only
worked by chance so far.
Task-number: QTBUG-82743
Change-Id: I64f20c6bf1e47737c7b927f79e1e78c1a1603741
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This class is not a private detail of QQmlContext. And it is incredibly
hard to see who owns what in there. Let's add some civilization ...
We enforce refcounting for QQmlContextData across the code base, with
two exceptions:
1. QQmlContextPrivate may or may not own its QQmlContextData.
2. We may request a QQmlContextData owned by its parent QQmlContextData.
For these two cases we keep flags in QQmlContextData and when the
respective field (m_parent or m_publicContext) is reset, we release()
once.
Furthermore, QQmlContextData and QQmlGuardedContextData are moved to
their own files, in order to de-spaghettify qqmlcontext_p.h and
qqmlcontext.cpp.
When the QQmlEngine is deleted, any QQmlComponents drop their object
creators now, in order to release any context data held by those.
Before, the context data would be deleted, but the object creators would
retain the dangling pointer.
[ChangeLog][QML][Important Behavior Changes] QQmlContext::baseUrl() does
what the documentation says now: It prefers explicitly set baseUrls over
compilation unit URLs. Only if no baseUrl is set, the CU's URL is
returned. It used to prefer the CU's URL.
Change-Id: Ieeb5dcb07b45d891526191321386d5443b8f5738
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Being careful, we can now save primitive values inline. We use the heap
pointer of QV4::Value as either QString* or QV4::Value* for complex
types. We cannot store persistent managed QV4::Value without the double
indirection as those need to be allocated in a special place.
The generic QVariant case is not supported anymore. The only place where
it was actually needed were the stream operators for QJSValue. Those
were fundamentally broken:
* A managed QJSValue saved and loaded from a stream was converted to a
QVariant-type QJSValue
* QVariant-type QJSValues were not callable, could not be objects or
arrays, or any of the special types.
* Cyclic references were forcibly broken when saving to a data stream.
In general the support for saving and loading of managed types to/from
a data stream was so abysmally bad that we don't lose much by dropping
it.
[ChangeLog][QML][Important Behavior Changes] When saving a QJSValue to a
QDataStream only primitive values or strings will be retained. Support
for objects and arrays was incomplete and unreliable already before. It
cannot work correctly as we don't necessarily have a JavaScript heap
when loading a QJSValue from a stream. Therefore, we don't have a proper
place to keep any managed values. Using QVariant to keep them instead is
a bad idea because QVariant cannot represent everything a QJSValue can
contain.
Fixes: QTBUG-75174
Change-Id: I75697670639bca8d4b1668763d7020c4cf871bda
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This is needed in a few places outside of declarative, so this change
restores the loc member in DiagnosticMessage and moves
QQmlJS::AST::SourceLocation into common's QQmlJS namespace/directory.
QQmlError is unaffected and retains only line/column.
Amends d4d197d062
Change-Id: Ifb9d344228e3c6e9e26fc4fe112686f9336ea2b2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Alex Shaw
Ulf Hermann
Fabian Kosmale
Andrei Golubev
Edward Welbourne
Lars Knoll
Maximilian Goldstein
Simon Hausmann
Qt Forward Merge Bot