| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
The static part can be used for compilation and won't resolve managed
objects. This allows us to remove all the remaining V4_BOOTSTRAP.
Change-Id: Id2f6feb64c48beb2a407697881aea8c0d791a532
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
| |
The tracing JIT won't be finished. Therefore, remove the parts that have
already been integrated.
Change-Id: If72036be904bd7fc17ba9bcba0a317f8ed6cb30d
Reviewed-by: Erik Verbruggen <erik.verbruggen@me.com>
|
|\
| |
| |
| | |
Change-Id: I9ba374f0c652628b7c84c36893c32b22529e384f
|
| |\
| | |
| | |
| | | |
Change-Id: I2f0b4f8543a448c9acffe0932e0fd67c0b7412f4
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is straight-forward to enable, with the minor adjustment that we
need to handle the case where a global lookup is done without a calling
qml context (worker script). We don't know at compile time whether a
script will be imported directly or used as a worker script, so we have
to generate the global qml lookup instruction regardless and handle it
at run-time.
Change-Id: Ia033afa214d919d906c676498dd3eceb1c5639d8
Reviewed-by: Michael Brasser <michael.brasser@live.com>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|\| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/qml/compiler/qv4compileddata_p.h
src/qml/jit/qv4baselinejit.cpp
src/qml/jit/qv4jithelpers.cpp
src/qml/jsruntime/qv4lookup.cpp
src/qml/jsruntime/qv4runtime.cpp
src/qml/jsruntime/qv4runtimeapi_p.h
src/qml/jsruntime/qv4vme_moth.cpp
src/qml/qml/qqmltypemodule_p.h
Change-Id: If28793e9e08418457a11fc2c5832f03cab2fcc76
|
| |\|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/qml/compiler/qqmltypecompiler.cpp
src/qml/compiler/qv4bytecodehandler.cpp
src/qml/compiler/qv4codegen.cpp
src/qml/compiler/qv4compileddata_p.h
src/qml/compiler/qv4compiler.cpp
src/qml/compiler/qv4instr_moth.cpp
src/qml/compiler/qv4instr_moth_p.h
src/qml/jit/qv4baselinejit.cpp
src/qml/jit/qv4baselinejit_p.h
src/qml/jsruntime/qv4function.cpp
src/qml/jsruntime/qv4vme_moth.cpp
Change-Id: I8fb4d6f19677bcec0a4593b250f2eda5ae85e3d2
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When resolving names in the context of QML bindings, we now direct
runtime access to QQmlContextWrapper::resolveQmlPropertyLookupGetter. At the
moment this does basically the same as Runtime::method_loadName, which
we called earlier. However this now provides the opportunity to optimize
lookups in the QML context in a central place.
When performing a call on a scope or context object property, we also
did not use a CallName() instruction - which would have gotten the
thisObject wrong - but instead we use a dedicated
CallScopeObjectProperty and CallContextObjectProperty instruction. These
rely on identifying these properties at compile time, which goes away
with lookups (and also doesn't work when using ahead-of-time
compilation). Therefore the qml context property lookup is using a
getPropertyAndBase style signature and
Runtime::method_callQmlContextPropertyLookup uses that.
For the tests to pass, some error expectations need adjusting. In
particular the compile-time detection of write attempts to id objects is
now delayed to the run-time.
The old code path is still there and will be removed separately in the
next commit (as it is massive).
Task-number: QTBUG-69898
Change-Id: Iad1ff93d3758c4db984a7c2d003beee21ed2275c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is the in a series of patches for a JIT that can use traced
information to generate better code. In this patch, traced information
is not used/stored yet. It allows testing the basic infrastructure
without trying to do any optimizations, therefore making it easier to
debug, test, and review.
Change-Id: I589bdadf731c36542331abe64e1b39e305b6723e
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 we can't resolve the variable and are executing eval code,
we need to look it up by name, and not generate a lookup in the
global object.
Change-Id: I693b3b714651911f72620160bfc463d6dbb00820
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch allows QML to access let/const variables defined in JS files.
Detailed changes:
- The recently added ContextType::ScriptImportedByQML is changed to avoid
creating Push/PopScriptContext instructions, similar to
ContextType::ESModule.
- QV4::Module is changed to also work with CompilationUnits which are not
ESModules. In this case QV4::Module will behave as if all lexically scoped
variables were exported.
- CompilationUnit is changed to support instantiating and evaluating
QV4::Modules for non-ESModules as well.
- QQmlTypeLoader is changed to always create QV4::Modules for evaluating
scripts. For the non-ESModule case, the QV4::Module is evaluated inside a
QV4::QmlContext, as before.
- A pointer to the QV4::Module is added to QV4::QQmlContextWrapper, and used
in virtualGet to access the let/const variables in the CallContext. Access
is read-only.
Fixes: QTBUG-69408
Change-Id: I6f299363fdf5e1c5a4a0f1d9e655b4dc5112dd00
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Add new enum value QV4::Compiler::ContextType::ScriptImportedByQML, which
behaves exactly the same as ContextType::Global. A follow-up patch will change
the behavior slightly.
Task-number: QTBUG-69408
Change-Id: I20d27804fd1433f2229704546bcd78a0ac108c01
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Their use may trigger setting c->requiresExecutionContext on the module
context, which is correct. However, unlike functions, modules at
instantiation time always have their context created ahead of time (to
populate imports). Therefore we must not emit call context creating byte
code instructions where we'd end up storing exports in the wrong place.
Change-Id: Id1264f1cfa6a7f1cd94247ffe71938bc9c5c3ff9
Fixes: QTBUG-70632
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
| |
Change-Id: I1855eb303225d1784b019f8eebab0ad8bf2cdf5e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
| |
Change-Id: I4c0cfc3a120fc0b246760886b576e92d3f7623ff
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
| |
Default export variables should follow lexical scope and live therefore
in the dead temporal zone (15.2.3.8).
Change-Id: I959a1dc1cdd430825d6d207138efaef23394bd04
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we access a lexically scoped variable after the initializer, then we
know it's either initialized or at least undefined, so we don't need to
do the TDZ check anymore.
The ES tests ensure that we don't optimize too much and the newly
revived tst_v4misc test ensures that we do not generate the TDZ check
instruction for certain scenarios.
Change-Id: I6706d1feb22217f323124ee698ebadb70324693b
Reviewed-by: Lars Knoll <lars.knoll@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>
|
|
|
|
|
|
|
|
|
| |
When registering a default export, make sure that the local name
points either to an entry that we've entered into the environment or
the synthetic entry we create.
Change-Id: I37e160dc1e3231214bb68f72d6bb0746d7aee3b3
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Default export declarations require a binding setup step at run-time, so
we hook it into the ESModule's statement list to make it visible to the
code gen visitor.
We also reserve local slot zero for the default export.
Change-Id: Ie064caad0422b92cfdadbd7d94db72a05e95c0cc
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>
|
|
|
|
|
|
|
|
|
| |
This makes them really const. The codegen needs some smaller changes
to ensure that writing to the variable when it's being defined is
allowed.
Change-Id: I781b4bc9c0e0397b9d00cad3daf758a062c17600
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
While the old code was also leading to correct results,
it was less efficient, as we would have added the
ConvertThisToObject instruction multiple times (once
for each block that uses 'this'.
Change-Id: Ia1f99b681b4494110d189f1bb6dded18fa413b53
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
There's no need to force lookups by name in an outer function
just because an inner function uses eval(). The lookup by name
is only required on the call context level, where eval() could
add new variables.
Change-Id: I8cad6d27524f496304342dfe1449ea913ef99fca
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Create a Block scope per iteration as defined in the ES spec. So
closures created inside the loop will remember the iteration variable
at that loop iteration.
Add support for destructuring of the left hand side expression or
declaration.
Change-Id: Id06ef94e2a4b93646827da4f6ce922eb436e5a31
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
| |
Change-Id: Ib60b56ac6a7111446e01235564a4cf92ad8ad025
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>
|
|
|
|
|
| |
Change-Id: Ib2968d4da22eab06b8a82eb7697d5e9fce6dc43d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
| |
Variables do not escape if they are being used from an
inner block in the same function.
Change-Id: I494861edf9d8a492930797928a3137362082d084
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Add a CompilerContext for with, whose only purpose it
is to trigger variable lookup by name. This avoids looking
up variables declared inside the with() {} block by name and
we do not lookup variables outside the with block by name
neither anymore.
Change-Id: I52e9fb2daa9601f9e5102714c002dc506ad5ed23
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: I0e98ccba9ae3026cd8bfdc4cae100f280b5aa22c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Move variable resolving into the context, and avoid creating
ExecutionContext's whereever we can. This prepares things for
block scoping, where this becomes rather important to be
able to achieve decent performance.
Change-Id: Idf3d3c12cf348a2c3da01989c26c8529ceb36c12
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
| |
And make it an enum class. The new name fits better, as it's mainly
used to determine the type of the context when parsing. Also already
added the 'Block' value that will be needed.
Change-Id: I70d963b6a0b22db1a3c607cce6bdd2054b29e000
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Repeatedly entering a context that was entered before would result in
leaking the previously entered context. This can happen when compiling
child objects in a QML file, which is done recursively. So before
compiling the bindings/function in the child object, first the global
context and then the QML context are entered.
The fix is to re-use the global context, as it's the same anyway for all
objects in the same module. And we can remove entering the QML context,
because nothing is in there, and we don't put anything in it ever.
Change-Id: Ib1c4259d2dec22df46e96edb65bc3d377e52e671
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
And changed the namespace of those classes to
QV4::Compiler.
ScanFunctions should over time also move into its
own file.
Change-Id: If084acea4a9a20b9c79ad47dac19e02dc720e098
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|