qt/qtdeclarative.git/src/qml/jsruntime/jsruntime.pri, branch wip/scenegraphng

Make sure we don't include qv4stackframe_p.h in qmldevtools

2019-05-10T10:35:18+00:00

The only thing we need is CallData, which is now provided as separate
file.

Change-Id: Iccbab67ac30d09077075b200f18d1d694f3ecb2a
Reviewed-by: Simon Hausmann

Move qv4string{_p.h|.cpp} out of the devtools

2019-05-10T07:37:14+00:00

The only thing we actually need is toArrayIndex() and that is a static
method. We provide it in a separate file.

Change-Id: I86b11e3d81a319202a0babacd17d87e7816ac88a
Reviewed-by: Simon Hausmann

Move compileModule() into qv4codegen.cpp

2019-05-08T12:05:30+00:00

This is a better fit for the method. In turn, remove all the
V4_BOOTSTRAP conditions from qv4engine_p.h and make sure we don't
include or compile it in bootstrap mode.

Change-Id: I5933b0724e561313ca20c420b83e4d70e63bddf5
Reviewed-by: Simon Hausmann

Move workerscript to its own module

2019-05-06T07:15:20+00:00

Change-Id: I778cfe842ddf1c600a837d8f2061a338887eed95
Reviewed-by: Lars Knoll

V4: Don't build the win64 function table hook on winrt

2018-12-11T08:55:45+00:00

Apparently WinRT doesn't have RtlAddFunctionTable.

Change-Id: I491b1eac1429b9ab3bc714a69e98760446cf9aeb
Fixes: QTBUG-72294
Reviewed-by: Simon Hausmann

V4: Generate function tables on 64bit windows

2018-12-03T08:28:36+00:00

In order for global exception handlers to be called reliably, the runtime
needs to unwind through JIT-generated code. This can be facilitated by
installing a "function table" for each JITed function that specifies "use
the frame pointer".

Also make sure to generate a function table for JIT'ed regular
expressions. Those were forgotten also in the linux case.

Fixes: QTBUG-50061
Change-Id: Ib0b8ae9356ed80afe1cab017e36efa4ccbe73f90
Reviewed-by: Simon Hausmann

QML Engine: Support for JavaScript Promises

2018-10-11T08:27:48+00:00

Support for JavaScript Promises.

Change-Id: I90ce328b35f3bdf3fd666a8829f22b5d56b6f861
Reviewed-by: Simon Hausmann

Partial Atomics support

2018-08-26T16:59:33+00:00

Implement support for basic atomic operations on
SharedArrayBuffers.

Half of the methods still need a proper implementation.

Change-Id: Ia88da358e0c2ae6d28e9bcc1feb8980b6f51a812
Reviewed-by: Simon Hausmann

Add support for compiling ES modules ahead of time

2018-08-17T11:06:18+00:00

This is also pretty straight-forward by adding .mjs as supported
extension in the qmake and cmake support.

This also tweaks qv4engine.cpp to share the same module compilation
function across all code paths.

Change-Id: Ia0e23c78a794f2330ecf8f991ee6ea948f4ac89d
Reviewed-by: Qt CI Bot 
Reviewed-by: Lars Knoll

Add initial basic support for ES6 modules

2018-08-09T13:18:39+00:00

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 
Reviewed-by: Lars Knoll