| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
We need a CompilationUnit that only holds the data needed for
compilation and another one that is executable by the runtime.
Change-Id: I704d859ba028576a18460f5e3a59f210f64535d3
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>
|
| |
|
|
|
|
|
|
| |
Object::getOwnProperty never modifies the object,
so make it a const member function.
Change-Id: I175bb45d61a66a1d9f577c087129562d44d62e17
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
|
| |
|
|
|
| |
Change-Id: I045a4844c06df9232cc8b04485ab0a39bb990e3f
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Accessing uninitialized imports through the module namespace object
should throw a reference error. Unfortunately we can't do this check on
the caller side of the namespace object get, as we have no idea that
we're talking to one. Therefore we must throw in the vtable methods.
When checking via Reflect.has(), the properties should be reported as
existing. This means providing a virtual hasProperty() in the module as
well as changing Reflect::method_has to use the vtable method instead of
doing a get (which would throw).
Change-Id: Ic0ec51de3832c6a67044fc8f689ac534f349c1b6
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
| |
|
|
|
|
|
| |
They must be sorted, no duplicates and only one default entry at most.
Change-Id: Ia9c0e54a761ce7cbfebb837330bf3769d505eb3b
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The import via
import * as foo from "./bar.js"
allows accessing all exports via the special namespace object. This is
conceptually quite similar to the existing import of .js files in
QtQuick.
Change-Id: Ia6d79342f0884a89dfe4dc07316570ca7789cac0
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>
|
