| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Collect type information about values used in a function. These include
all parameters, and the results of many bytecode instructions. For array
loads/stores, it also tracks if the access is in-bounds of a
SimpleArrayData.
Collection is only enabled when the qml-tracing feature is turned on
while configuring.
In subsequent patches this is used to generated optimized JITted code.
Change-Id: I63985c334c3fdc55fca7fb4addfe3e535989aac5
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
|
|
|
| |
If a tagged template gets evaluated multiple times, the
underlying template object is shared.
Change-Id: Ie2f476fbc93d5991322ce1087c42719a8d8333ae
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
| |
Doing the tail call in the runtime will come in a follow-up patch
Change-Id: I8224aac0edbdc765ee9b97703948edd52fd33f3e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
| |
Change-Id: I5b054b59519ed825459a5b0b0a7cd2c6fc8a3797
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
| |
Change-Id: Id1bba1a729124bccb8a90dcf40252fe5c69d27a3
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an exception happens during destructuring, IteratorClose
needs to be called, unless the exception happened inside the
IteratorNext call (in that case the iterator is assumed to be
invalid and we shouldn't call close on it).
Implement this, by ensuring that we set the done return variable
of IteratorNext to true whenever IteratorNext throws an exception.
IteratorClose will check the done state and not do anything in that
case.
Change-Id: I73a27f855f2c4d3134b8cc8980e64bf797d03886
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
| |
Change-Id: Ia520d43ea2c29c16cfc8ffc86a32187a78848502
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With const and let it is possible to access the declared member before
initialization. This is expected to throw a type reference error at
run-time.
We initialize such variables with the empty value when entering their
scope and check upon access for that. For locals we place the lexically
scoped variables at the end. For register allocated lexical variables we
group them into one batch and remember the index/size.
Change-Id: Icb493ee0de0525bb682e1bc58981a4dfd33f750e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The entry point from the parsing perspective into modules is not
QV4::Script but QV4::ExecutionEngine::compileModule.
For convenience, the ESModule AST node gets a body, which is the
statement list connected between the ModuleItemList items that are not
import/export declarations.
The QV4::Module allocates a call context where the exported variables
are stored as named locals. This will also become the module namespace
object.
The imports in turn is an array of value pointers that point into the
locals array of the context of the imported modules.
The default module loading in ExecutionEngine assumes the accessibility
of module urls via QFile (so local file system or resource). This is
what qmljs also uses and QJSEngine as well via public API in the future.
The test runner compiles the modules manually and injects them, because
they need to be compiled together with the test harness code.
The QML type loader will the mechanism for injection in the future for
module imports from .qml files.
Change-Id: I93be9cfe54c651fdbd08c5e1d22d58f47284e54f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
examples/quick/demos/photoviewer/i18n/qml_de.ts
examples/quick/demos/photoviewer/i18n/qml_fr.ts
examples/quick/demos/photoviewer/photoviewer.pro
examples/quick/demos/photoviewer/qml.qrc
src/qml/compiler/qv4instr_moth_p.h
tests/auto/quick/qquickanimations/tst_qquickanimations.cpp
Change-Id: Ibea76b468577c2a68bd305cee82ae6444d0f8073
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When decoding the bytecode, we must be careful to avoid that the
compiler generates aligned memory access instructions, because the
current byte code pointer may not be aligned at all.
When decoding integer parameters, the existing code would expland to
qFromLittleEndian(reinterpret_cast<const int>(code)[-nargs+offset])
which loads the integer from the array before passing it by value to
qFromLittleEndian.
[ChangeLog][QtQml] Fix crashes with unaligned memory access on ARM.
Task-number: QTBUG-69328
Change-Id: Ib1c66113e2b8e103ad6f5de11443a561d23a4185
Reviewed-by: Bhushan Shah <bshah@kde.org>
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instructions always occupy two numbers, an even and the following
odd one, for the single byte and four byte encoding.
An instruction of 0x0 is now a NOP, but 0x1 implies that the
instruction type is using two bytes, and the following byte needs
to be read as well to get the correct instruction type.
Encoding and decoding of those two byte instructions is fully
transparent, and adding more instructions now doesn't require
any special handling.
The first 127 instructions in the FOR_EACH_MOTH_INSTR macro will
get a single byte encoding, the remaining ones will use two bytes.
When adding new instructions, make sure to put often used and fast
instructions into the first 127 instructions, while adding rarely
used (or slow) instructions to the end (before Debug though).
Change-Id: Id772a109641ab68feb228c3abd05f41ae7075e94
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Change the encoding, so that even instructions are short ones,
odd instructions long. This implies that the lowest bit encodes
whether an instruction is short or long (1 vs 4 byte encoded).
This prepares for allowing us to extend the totoal number of
instructions beyond 128.
Change-Id: I4732e7241d3593b24ad25cd69555edc25f38d2f6
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Those are mostly working now, but when calling super properties
the this object is not setup correctly.
Change-Id: Ib42129ae6e729eeca00275f707f480371b7e42a5
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
GetLookup and GetLookupA were doing exactly the same thing. Only keep
the version that expects the base object in the accumulator and
rename it to GetLookup.
Change-Id: Ia14256880cef23f7b70d8c7e6bb74aba371b8d9a
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Implement super call support for class constructor
functions.
Change-Id: I3c64276234689cf4f644b095e0fc8ca1c634ac53
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Most of the class creation is done inside the runtime
in the CreateClass method. Added a corresponding
instruction to the interpreter and jit.
The compiled data now contains an array of classes
containing the compile time generated layout of the class.
Currently, classes without an explicit constructor and
classes with inheritance are not supported.
Done-with: Yulong Bai <yulong.bai@qt.io>
Change-Id: I0185dcc1e3b0b8f44deff74e44a8262fc646aa9e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Function calls with thread are modelled by pushing
an empty value in front of every argument that
requires spreading. The runtime methods callWithSpread
and constructWithSpread then take care of spreading
out the arguments.
Change-Id: Ie877c59d3d9d08fc5f20d7befb7153c7b716bf30
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| | |
Always use the overload where the value is in the accumulator.
Change-Id: I6a3d81fea7aae957e0cf6efd123d7739f8880c95
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
The delete operator is rarely used, so it's simpler to
unify these into one DeleteProperty instruction.
Change-Id: I8c0d4455b35efb03db2ab0010df70030d774a6ae
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| | |
Change-Id: I117687939e0f02d801dbad8de7761b4c799f2035
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The old code was rather convoluted and expanded to quite
a bit of bytecode. It was also very hard to fix some
of the remaining issues with unwinding in there.
The new code handles unwinding a bit differently. Basically,
we now have three instructions to do what the spec requires.
SetUnwindHandler is the same as the old SetExceptionHandler
instruction. It basically tells the runtime where to jump to
to handle any abrupt completion (ie. throw/break/continue/return)
that requires unwinding.
UnwindToLabel is a new instruction that is used for unwinding
break/continue/return statements. It takes two arguments, one
telling the runtime how many levels to unwind and the second
a target label to jump to when unwinding is done.
UnwindDispatch is the third instruction and is invoked at
the end of each unwind block to dispatch the the parent
unwind handler if required and thus implement the support
for the levelled unwinding.
Change-Id: I079a39d0d897b3ecc2f0dc631ca29b25eae05250
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It's being used for more than just exception handling,
unwinding for return or break/continue statements also
goes through those handlers.
Change-Id: I145c7909540a1adca431de6a98d9c115ddf23612
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Our method to create object literals wasn't compliant with the
ES7 spec, as we would in some cases re-order the properties.
This violated the spec which required properties to be created
in order, so that for-of would also iterate over them in creation
order.
As a nice side effect, this simplifies the code and gets a couple
of test cases using computed property names to pass.
Task-number: QTBUG-62512
Change-Id: I6dfe004357c5d46a0890027f4fd9e2d1e1a2a17a
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| | |
Change-Id: Icaa6fa5dc0fa9a03127b0c28dfd84b9b3057212e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
| |
| |
| |
| |
| | |
Change-Id: I11721025fd3df5efbcc6f6c8cb31fa2f89ead03f
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There's no need for a temp register to store the old context in,
as PopContext can simply retrieve the old context from
the current one.
Change-Id: Ife9cfdff7fa8e47fc71e844a7798de88dbc79e26
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Array destructuring assignments require a call to iterator.return if
the iterator hasn't been exhausted during destructuring.
Change-Id: I39fe4bc01bef6fb2ad3bda92caf6779fbbddc8e2
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The instruction now writes the value into a stack slot,
and returns the done state in the accumulator. This should
make it easier to implement the IteratorClose functionality
required by the spec.
Change-Id: I8cc497c54b0d044bd3c68a5a1b774eea8b2740ef
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| | |
"var [x, ...y] = array" now works as intended.
Change-Id: I45238f27f468d0b0e14dc0e931c55c4f40043690
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Array destructuring should use iterator objects, not integer
indexes.
Change-Id: I769bb1d63246da6bc45233f7a6e9a8e5ddc53a4d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Added an IteratorNext instruction to fetch the next
iteration value (empty if the iterator is done).
This will also help to implement array destructuring without
requiring huge amounts of byte code.
Change-Id: If96c1e81471e5e2b0b7b2af122238d87741aa371
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Regular for loops also have a per iteration context for lexically
declared variables as well.
Change-Id: I35cb58bfb198c7dc32d70f41ea0ced7ddefcc37e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This requires a bit more work than simply pushing a
new BlockContext for the lexically declared variables,
as eval() and the Function constructor operate on the
global scope (including the lexically declared names).
To fix this introduce Push/PopScriptContext instructions,
that create a BlockContext for the lexically declared
vars and pushes that one as a global script context that
eval and friends use.
Change-Id: I0fd0b0f682f82e250545e874fe93978449fe5e46
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The support is basically at the same level as for for-in
at the moment.
Currently unimplemented:
* Destructuring
* Proper lexical scoping
* calling iterator.throw()/return() when required
Change-Id: If193ce0b054c4315fc16b7e174334a31b2730dcf
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add support for ES6 generators. Those are currently
always executed in the interpreter (we never JIT them),
to simplify the initial implementation.
Most functionality, except for 'yield *' expressions
are supported. 'yield *' will have to wait until we
support for(... of ...)
Change-Id: I7c059d1e3b301cbcb79e3746b4bec346738fd426
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Remove the need for a specialized catch context, instead
use a regular block context, that also captures the
catched variable.
This also removes the need to do lookups by name inside
a catch expression.
Change-Id: I8b037add7f423922e2a76b4c0da646ca7e25813a
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is still to some extend work in progress as
lexically scoped for loops won't yet do the right
thing.
let and const variables are still accessible before
they are declared, and the global scope doesn't yet
have a proper context for lexically declared variables.
Change-Id: Ie39f74a8fccdaead437fbf07f9fc228a444c26ed
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| | |
Change-Id: I58a21e70fdd040175b52465d6ba52e7fceaf6398
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| | |
Change-Id: I4b18a88e443f3b263cbb1e2b5ca1ebbd353afa98
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
| |
| |
| |
| |
| |
| | |
function foo(a, b, ...c) {...} now works correctly.
Change-Id: Ie442a0e7cc5e9dc4156e56b348bba305cced8531
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|/
|
|
|
|
|
|
|
| |
The parser can also handle rest parameters correctly, this will
however require some additional work in the runtime to support
it correctly.
Change-Id: Ib6f4d27683774966b2d2aac075494d2f5066d2a2
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Given the following expression
var x = MySingleton.MyEnumValue
where MySingleton is a QML (composite) singleton and MyEnumValue comes
from a QML declared enum, we had code in place up to (and including)
5.10 to attempt to optimize that expression to a enum constant at
compile time. In 5.10 that optimization does not exist anymore. In <=
5.10 we would also skip the optimization under certain circumstances
(too many statementes, etc.). The fallback that is in place for handling
this at run-time tried to be smart by avoiding the
QQmlContextWrapper::get lookup and return straight a reference to the
singleton as QObject. That works for regular property lookups, but it
fails when trying to look up something like an enum, that isn't a
meta-object property.
Change-Id: I1819b9d8ae06a3f595e067bf5b018c4065be76bb
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a function is called that is in a QML scope or a QML context, set
the 'this' object to the QML scope. This is done by introducing two new
interpreter instructions, which get the context passed in.
Note: this patch is 5.11 specific. 5.9 had a similair issue, but the
implementation is quite different, so that was fixed separately.
Task-number: QTBUG-66432
Change-Id: Ie43150cdd26360025895df28d31264985abf1c15
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
| |
Change-Id: Ie1b18dd00705b1913572b87c6968a63438e7a90c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
| |
We cannot build QML without interpreter anymore.
Change-Id: Ibc51240caa956132eef8753fa6c75939026930d5
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
| |
Ensure that the integer arguments for widely encoded instructions are
always encoded as little endian.
Change-Id: Iccd45aefb20b20d76fe1618d6706435142b202b9
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the difference of sign of the char type, byte code is encoded
differently on x86-64 than if it was on ARM and it also is decoded
differently. The problem at hand here was that negative jumps were
encoded as two-byte instructions (opcode and negative offset as byte) on
x86-64 when qmlcachegen is run. At run-time the negative offset was read
into a char type and consequently interpreted as a positive jump,
leading to crashes.
The explicit use of qint8 as signed byte type in encoding/decoding
sensitive parts avoids the decoding issue and should also result in
consistent encoding.
The added auto-test is (among other configurations) run in the CI under
qemu, which means the x86-64 host-built qmlcachegen will generate byte
code and the tst_qmlcachegen ARM binary will run under qemu and
reproduce this scenario.
Task-number: QTBUG-65521
Change-Id: I615628f53475dad38a41095c6e7ffea0c34d58ac
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Otherwise we get:
Internal error: assertion failed at: "shared/cfe/edgcpfe/il.c", line 9371
Task-number: QTBUG-64981
Change-Id: I9a4bd81eb9d1ffee23c22f818583c06f9e74433b
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to store the value-to-be-called in the accumulator. So the
generated bytecode looked like:
LoadReg r1
CallValue()
The first thing done in CallValue is to store the accumulator. So by not
loading the accumulator, we can actually remove the subsequent store,
which results in less interpreter instructions and one less store in
CallValue.
Change-Id: Icc7c8a5449bf369b9226d66bc6055cb705ef660e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|