So far we rely on QVariant::convert() and that only works in some
places and is expensive.
Change-Id: Ia6be7807c3d245148fcd4f4bed2ebc9e35ad52ff
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 7bcac62265)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This way we can identify which entry in a stack frame to amend when
processing an exception in generated code. However, negative line
numbers are also used to signal the position of "Ret" instructions.
Since you cannot throw an exception from a "Ret" instruction, those
cannot collide, but we cannot qAbs() the line number anymore when saving
it in the stack trace. We have to qAbs() it in all the places where it's
read.
Fixes: QTBUG-112946
Change-Id: I24dc4008fb7eab38e4d24e70211c22e46f1b72a7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 406a9e1301)
This is likely to lose some properties.
Fixes: QTBUG-106266
Change-Id: Ib5a2567d61635a5cf7b3abee7cfef0c073d59e63
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 4307755655)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
It should result in NaN, not in 0. The typedArray() test exposes that
ExecutionEngine::toVariant() also gets this wrong. Fix that, too.
[ChangeLog][QtQml][Important Behavior Changes] Converting a JavaScript
value to a double or float, for example by inserting it into a typed
array, now assumes JavaScript type coercion semantics. In particular,
converting a value that is not actually a number now results in NaN
where it previously sometimes resulted in 0.
Fixes: QTBUG-111179
Change-Id: If24444ae9014c8972761c565a6920f06699e485c
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit b9834e0ee9)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
It breaks unity builds, and declaring metatypes outside of the actual
class that uses them is generally a bad idea.
Change-Id: I0106667f6075aabc2fa3c9e5271d21b64f41e4c1
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
(cherry picked from commit e3831511de)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
They should either be the same size as int/uint or the same size as
longlong/ulonglong, but for some reason we get them as separate types.
Fixes: QTBUG-110767
Change-Id: I4c5826cfe6108e6f9722e6b3443bde13b2141b04
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Semih Yavuz <semih.yavuz@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry picked from commit 11bc79d7c6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
A JavaScript Date object can be backed by QDate, QTime or QDateTime.
Allow those to be written back.
Fixes: QTBUG-28981
Change-Id: Ic46b5c4daf75453f03e99470933cf179820e63ef
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
(cherry picked from commit 51089b3389)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Since we can produce QJSPrimitiveValue in metaTypeFromJS, we should also
handle the other direction.
Fixes: QTBUG-109867
Change-Id: I2c7598d19eba3e78d071ca3eceb32deda4d0ead8
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit e070b5aa39)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We need to explicitly cast to double if we are wrapping a number type
that's not natively accepted by the ctors.
As a side effect, correctly run conversions from generic QVariant to
QJSPrimitiveValue through the engine now. For that we need another
clause in metaTypeFromJS().
Since we are calling methods that return list types in the test, we need
to add another clause that converts JS arrays to list types. Otherwise
we cannot run that test in interpreted mode.
Task-number: QTBUG-109111
Change-Id: I87f7aafd24371d2c1ffe85569e1f2cd3a1979742
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit b13e22f274)
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
This re-introduces a stack bounds checker. The previous stack bounds
checker was removed in commit 74f75a3a12
because the cost of determining the stack base was deemed too high.
Indeed, determining the stack base on linux using the pthread functions
costs about 200.000 instructions and the cost grows with the number of
concurrently running threads.
However, by reading /proc/self/maps directly we can trim this to about
125k instructions. Furthermore, with the new implementation we only need
to do this once per engine. Calling JavaScript functions of the same
engine from different threads is not supported. So we don't have to
consider the case of checking the bounds of a different thread than the
one the engine was created in. Furthermore, we get a more accurate
number now, which means we don't have to re-check when we get near the
boundary.
Also, change QV4::markChildQObjectsRecursively() to use an actual
QQueue instead of being recursive. This avoids the stack from overflowing when the stack is already almost full, and was leading to
crashes in the stackOverflow tests.
Make the stack smaller for the the tst_qquickloader::stackOverflow{,2} tests to run faster in the CI (and avoid the timeout).
Task-number: QTBUG-106875
Fixes: QTBUG-108182
Change-Id: Ia5d13caa7d072526ff2a3e1713ec7781afc154a9
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
If you do that in JS you get "undefined" and "null", respectively. Our
C++-based conversion methods should do the same. The documentation for
QJSValue also suggests that QJSValue::toFoo() should behave like
qjsvalue_cast<Foo>(x). So far QJSValue::toString() produced "undefined"
and "null" while qjsvalue_cast<String>(x) produced an empty string.
[ChangeLog][QtQml][Important Behavior Changes] qjsvalue_cast<QString>(x)
now returns "undefined" for undefined JS values, and "null" for null JS
values. This is in line with what QJSValue::toString() does, and also
what JavaScript itself would produce when stringifying such values.
Previously, qjsvalue_cast would return an empty string for both,
undefined and null JS values.
Change-Id: Ib93f4157f092ed769dca946541ffbcfbd7317d4c
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Both types have functionality to write themselves back to the properties
they were loaded from on change, but so far we could not nest those
writes.
[ChangeLog][QtQml] You can now assign to properties of nested value
types and to elements of containers from QML functions. You cannot,
however, take references of such values and elements. This is in
contrast to non-nested value types and the containers themselves.
However, passing references of value types and containers around
generally leads to very confusing effects. Don't do this.
Fixes: QTBUG-99766
Change-Id: I74cb89e5c3d733b0b61e42969d617b2ecc1562f4
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Calling alloc with a qint64 parameter is a good indicator that we got
that value from Object::getLength. In that case, the value needs to be
sanitized with safeForAllocLength.
As a consequence, we notice that method_stringify did indeed use alloc
in an usasafe way; this is now fixed.
In a few other places, variables had to be changed from unsigned to
signed int (as the conversion is now ambiguous).
An even stricter check would be to only accepd a value of (not yet
existing) "sanitized_size_t" type. However, that requires more effort,
at it would each and every call-site, and is thus left as an exercise
for later.
Pick-to: 6.4 6.2 5.15
Fixes: QTBUG-107619
Change-Id: I3bba9be1e0aea72e11ccb6c168219b4591eb8f5b
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This extracts the check from Function.prototype.apply into a shared
function, and uses it in Reflect.apply, which has the same issue.
Pick-to: 6.4 6.2 5.15
Task-number: QTBUG-107619
Change-Id: I899464c86554f9bbb5270a95bbe3fe27531e9a27
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This is a semantic patch using ClangTidyTransformator as in
qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8:
auto QtContainerClass = anyOf(
expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o),
expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o));
makeRule(cxxMemberCallExpr(on(QtContainerClass),
callee(cxxMethodDecl(hasAnyName({"count", "length"),
parameterCountIs(0))))),
changeTo(cat(access(o, cat("size"), "()"))),
cat("use 'size()' instead of 'count()/length()'"))
a.k.a qt-port-to-std-compatible-api with config Scope: 'Container',
with the extended set of container classes recognized.
Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The success of the operation is visible from the return value in all
cases.
Change-Id: I93177785f76b8078ddd8eeb7d77143993fe80739
Reviewed-by: Semih Yavuz <semih.yavuz@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The data needs to be copied anyway if we are going to store it in
ScarceResourceObject. We can just as well copy it from the void pointer.
Change-Id: Ic106221138b1236a6ddea20cfdb468c6fbe3e1c3
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
When loading from value type properties we left quite a few trivial
conversions on the table and went via QVariant instead. Add them.
It would be nice to unify the various places where we switch over the
trivial types, but I don't see an easy way to do so right now.
Change-Id: I9dcb29ce147a2f282e7ea6903a7af8a4b3038af6
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
We allow value types to be created
1. by calling Q_INVOKABLE constructors
2. by setting their values from properties of a JS object
Both have to be opted into by setting a class info. If opted into, these
options override the existing methods. When a a type can be created by
setting its properties, that implies you can also initialize it using an
invokable constructor. However, when given a JS object, the properties
method is used.
We keep this internal and undocumented for now. As the last try (the
create(QJSValue) methods and QJSValue ctors) was not that stellar, let's
first wait a bit and see if we're getting it right this time around.
Fixes: QTBUG-106480
Change-Id: I767230924afcba032d501846cc3263dad57b7bf0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Wherever we need an engine in there, we also have a managed value to get
it from. This relieves us from the requirement to drag an engine around
wherever we want to call toVariant().
Change-Id: Ib95d02b5fbf5eaa494214e337c9b700e97e5e0df
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Drop unnecessary includes detected by clangd-iwyu.
Add new includes due to the transitive includes. Also, some of the
includes were detected as unused even if they were actually in use.
In those cases, use angular brackets instead of "" which deceives
the tool not to complain.
Affected subfolders: Debugger, Compiler, JsApi, JsRuntime, Memory,
Parser
Task-number: QTBUG-106473
Change-Id: I01d996a2a2ba31cbbc5f60f5454c8f850298f528
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The only thing we still need is createValueType(). That is by itself
debatable, and it can be static.
Change-Id: Id092f547415c600b7d1db01f78661c287e7f4979
Reviewed-by: Semih Yavuz <semih.yavuz@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We can allow
a, overriding data members of globals, such as Error.name
b, adding members that don't clash with any internals
c, any manipulation of toString(), toLocaleString(), valueOf(),
and constructor
To that effect, add a "Locked" flag to our internal classes. If that is
set, disallow changing prototypes and when defining a property, check if
it shadows any non-configurable property. Furthermore, make all
non-primitive properties that are not meant to be overridden
non-configurable and non-writable.
constructor, toString(), toLocaleString() and valueOf() are exempt
because they are explicitly meant to be overridden by users. Therefore,
we let that happen and refrain from optimizing them or triggering their
implicit invocation in optimized code.
[ChangeLog][QtQml][Important Behavior Changes] The JavaScript global
objects are not frozen anymore in a QML engine. Instead, they are
selectively locked. You can extend the objects with new members as long
as you don't shadow any existing methods, and you can change or override
data members. This also means that most methods of Object.prototype,
which was previously exempt from the freezing, cannot be changed
anymore. You can, however, change or override constructor, toString(),
toLocaleString() and valueOf() on any prototype. Those are clearly meant
to be overridden by user code.
Fixes: QTBUG-101298
Task-number: QTBUG-84341
Change-Id: Id77db971f76c8f48b18e7a93607da5f947ecfc3e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We can access the same QObject in const and non-const contexts. Both
should be possible. Store the const objectwrapper in
m_multiplyWrappedObjects. That's somewhat slow, but const QObjects are
rather rare.
Pick-to: 6.4
Fixes: QTBUG-98479
Change-Id: I047afc121f5c29b955cd833e0a2c8299fc52b021
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Previously we've assumed the whole allocation can be used, even though
the first and the last page are actually not usable. This makes a
difference when the size of the guard pages grows, such as on macOS,
which these days has 16k pages.
Add the extra guard page size to the amount of memory to be allocated in
order to fix the calculation.
Pick-to: 6.4 6.3 6.2 5.15
Fixes: QTBUG-93188
Change-Id: I0ebece94449da3127e9a78a19d8a22722ad8d698
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
So far, you could only use them from pure JavaScript programs. Also, fix
re-exporting parts of native modules.
Fixes: QTBUG-105901
Change-Id: I170017083284e6457b1aa0c6e606fd26227edae3
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Updating the prototype usage is very expensive. We only need to do it
once there are lookups. Before the engine is fully initialized there are
no lookups.
Change-Id: Ic919a1f8955718d417e7747ea72e009d443c42fd
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
For objects with circular structures we generate a proper error message
and fail earlier. For objects with excessive recursion we throw a range
error rather than crashing.
This behavior is modeled after node's behavior in such circumstances.
We use the existing stack overflow detection to determine when to throw
the range error. Testing shows that on windows the limit was
insufficient. Lower it.
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-92192
Change-Id: I25dd302f65f359111e42492df3c71549c4ed7157
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
We need to preserve them as they notify us about protoId related
changes. In order to avoid wasting heap space in case many properties
are added and removed from the same object, we put a mechanism in place
to rebuild the InternalClass hierarchy if many redundant transitions are
detected.
Amends commit 69d76d59ce.
Pick-to: 5.15 6.2 6.3 6.4
Fixes: QTBUG-91687
Task-number: QTBUG-58559
Change-Id: I3238931b5919ed2b98059e0b7f928334284ce7bf
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The test revealed that the fill() method of JS arrays did not properly
range-check its parameters. Fix that, too.
[ChangeLog][QtQml][Important Behavior Changes] QQmlListProperty behaves
like a JavaScript Array now. You can use map(), reduce(), forEach() etc
on it. This also includes a slight change of behavior to the push()
method. push() now returns the new list length, and it checks the length
to not exceed UINT_MAX.
Task-number: QTBUG-58831
Fixes: QTBUG-49613
Fixes: QTBUG-99041
Change-Id: Ia64d73fb704449c280fbbc7ddcf20f4698c82e09
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
They were replaced with an extension to the Qt singleton in Qt6.
However, the singleton is only available when QtQml is imported.
We can easily provide the enums using the metaobject of the Qt
namespace.
Pick-to: 6.4
Change-Id: I5f58d30c749c0cb9e531df180a5cbe75c92e1aa6
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Pick-to: 6.4
Task-number: QTBUG-67283
Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
As we can store sequence types in QJSValue, we should be able to
retrieve them, too.
Move the declaration of the QV4::Sequence struct into a header to make
it less of a hassle to identify sequences.
Change-Id: I3e45bfe193c669107f90cd6c502765c0c9f60fb0
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
When converting a JS value to a variant, if we notice that we get a
QJSValue again, there is no point in trying to convert it further. We'll
just run into infinite recursion.
Pick-to: 6.3
Fixes: QTBUG-102545
Change-Id: I0a40e21287e5460e5e214101aabe8d2b4bf0afad
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
QML can create a function which holds a closure in the cases like:
onSignal: function() { ... }
If the left-hand side is a signal handler (or similar), we want to
execute the *inner* function when a signal is called, not the outer
one. However, under certain conditions (e.g. we use `this`), the
outer function must also be called beforehand to correctly setup the
calling scope for the inner function
Thus, make the QQmlEnginePrivate::executeRuntimeFunction() do that:
always call an outer function first and then the inner one if present.
This creates an overhead when dealing with certain signal handlers but
we could optimize it later if needed
Note that the case `property var prop: function() { return 42; }` where
a property contains a callable function is no longer supported by the
executeRuntimeFunction() routine (we always call the inner code now).
This is fine since qmltc (the main beneficiary of the routine) does not
rely on this functionality when dealing with property bindings
Given the change, qmltc can be simplified to only work with absolute
function indices, ignoring the nesting problem altogether
Change-Id: I61f61587b6fe700cb695b3b7a213d9cfab0eb746
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Adapt maximum stack size to not run into segfaults
due to stack overflow.
Pick-to: 6.2 6.3
Task-number: QTBUG-102384
Task-number: QTBUG-96788
Change-Id: I4ba3518369c822b1b2d93388817beb7f86d19cdc
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
... and do it only for the first engine (ie engineId == 1). The engineId
is determined using atomic operations, so this is safe now.
Pick-to: 6.3
Task-number: QTBUG-73271
Change-Id: Ife38213fe04e26f35425a29230a2e3b586572dd2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
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>
Ulf Hermann
Fabian Kosmale
Edward Welbourne
Marc Mutz
Semih Yavuz
Thiago Macieira
Lucie Gérard
Andrei Golubev
Andreas Buhr