aboutsummaryrefslogtreecommitdiffstats
path: root/src/qml/compiler/qv4compilercontext.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Split QV4::Value into a static and a dynamic partUlf Hermann2019-05-311-1/+1
| | | | | | | | 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>
* Remove tracing JIT infrastructureUlf Hermann2019-04-291-22/+0
| | | | | | | | 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>
* Merge remote-tracking branch 'origin/5.13' into devQt Forward Merge Bot2019-03-291-1/+1
|\ | | | | | | Change-Id: I9ba374f0c652628b7c84c36893c32b22529e384f
| * Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-03-271-1/+1
| |\ | | | | | | | | | Change-Id: I2f0b4f8543a448c9acffe0932e0fd67c0b7412f4
| | * Enable lookups for imported scripts and worker scriptsSimon Hausmann2019-03-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge remote-tracking branch 'origin/5.13' into HEADUlf Hermann2019-03-221-2/+5
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-03-211-2/+5
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| | * Implement dummy QML lookups for "global" variablesSimon Hausmann2019-03-201-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | V4: Add IR that can use traced information to JITErik Verbruggen2019-03-041-3/+1
|/ / | | | | | | | | | | | | | | | | | | | | 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>
* / V4: Collect trace information in the interpreterErik Verbruggen2019-01-251-0/+24
|/ | | | | | | | | | | | | | | 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>
* Properly mark variables as unresolved when accessed from evalLars Knoll2018-11-161-1/+1
| | | | | | | | | 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>
* Expose let/const variables from imported JS scriptsJüri Valdmann2018-11-021-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Clone ContextType::Global as ContextType::ScriptImportedByQMLJüri Valdmann2018-11-011-4/+5
| | | | | | | | | | 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>
* Fix use of lexically scoped variables in modulesSimon Hausmann2018-09-231-2/+2
| | | | | | | | | | | | 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>
* Fix new.target access from eval()Lars Knoll2018-09-071-0/+7
| | | | | Change-Id: I1855eb303225d1784b019f8eebab0ad8bf2cdf5e Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* fix accesses to this in arrow functionsLars Knoll2018-09-051-0/+7
| | | | | Change-Id: I4c0cfc3a120fc0b246760886b576e92d3f7623ff Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Fix scoping of the default exportSimon Hausmann2018-08-291-8/+9
| | | | | | | | 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>
* Optimize access to lexically scoped variablesSimon Hausmann2018-08-291-4/+20
| | | | | | | | | | | | | 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>
* Implement the dead temporal zoneSimon Hausmann2018-08-281-10/+46
| | | | | | | | | | | | | | 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>
* Fix initialization of default exported functions and generatorsSimon Hausmann2018-08-151-3/+6
| | | | | | | | | 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>
* Fix support for default exports in modulesSimon Hausmann2018-08-101-0/+5
| | | | | | | | | | | 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>
* Add initial basic support for ES6 modulesSimon Hausmann2018-08-091-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* throw a type error when trying to write to a const variableLars Knoll2018-06-261-0/+3
| | | | | | | | | 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>
* Set the usesThis flag on the function contextLars Knoll2018-05-231-1/+2
| | | | | | | | | | 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>
* Cleanup handling of direct evalsLars Knoll2018-05-231-1/+3
| | | | | | | | | | 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>
* Simplify Push and PopContext instructionsLars Knoll2018-05-231-24/+19
| | | | | | | | | 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>
* Improve for-in and for-of supportLars Knoll2018-05-111-2/+13
| | | | | | | | | | | | 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>
* Support destructuring inside catch()Lars Knoll2018-05-111-2/+2
| | | | | Change-Id: Ib60b56ac6a7111446e01235564a4cf92ad8ad025 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Ensure we have a lexical scope for global codeLars Knoll2018-05-111-33/+43
| | | | | | | | | | | | | | | 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>
* Fix sanity checks when declaring variablesLars Knoll2018-05-021-5/+7
| | | | | Change-Id: Ib2968d4da22eab06b8a82eb7697d5e9fce6dc43d Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Avoid excessive creation of contextsLars Knoll2018-05-021-1/+0
| | | | | | | | 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>
* Cleanup handling of with() statementsLars Knoll2018-05-021-2/+2
| | | | | | | | | | | 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>
* Rework catch context handlingLars Knoll2018-05-021-12/+22
| | | | | | | | | | | | 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>
* Add support for proper lexical scopingLars Knoll2018-05-021-24/+71
| | | | | | | | | | | | | 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>
* Split out the generation of indices for locals and registersLars Knoll2018-05-021-21/+34
| | | | | Change-Id: I0e98ccba9ae3026cd8bfdc4cae100f280b5aa22c Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Refactor variable resolvingLars Knoll2018-05-021-0/+145
| | | | | | | | | | 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>
* Rename the CompilationMode enum to ContextTypeLars Knoll2018-05-021-2/+2
| | | | | | | | | 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>
* Fix leak of compiler contextsErik Verbruggen2018-04-101-0/+2
| | | | | | | | | | | | | | | 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>
* Split up qv4codegen into several filesLars Knoll2017-07-031-0/+82
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>