QML_{NAMESPACE_}EXTENDED and QML_EXTENDED_NAMESPACE are supposed to
behave differently when it comes to visibility of properties, methods,
etc. Thus, make it so by actually using different class infos and
updating QQmlJSScope. Use a HasExtensionNamespace flag to differentiate
between extension and extension namespace (whenever one of them is set)
Update the internal search routine that traverses the base types and
extensions of the given scope
Change-Id: Ifafbb22f831f5b128e431a3e65c514ffdf65eb73
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Do not go over extension's base types since this is not how the engine
logic work. Instead, only assess the direct extension type when
traversing the base type hierarchy. The special cases are value types
which still need base type extension traversal (e.g. due to Number
and NumberPrototype extensions on primitives) and QObject type itself
(we expect to see ObjectPrototype properties / methods of it)
Pick-to: 6.3 6.2
Change-Id: I92ba979202b33f16e1a7b948d4f1e79df37f2669
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The name of the module's folder should match the URI and
application binary dir should be provided as an extra import
path for the module to be discoverable
Change-Id: I00d67593d18dc86c0929f8a64b2c165221a4758a
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Grouped properties do not bind to a default property and they are not
object definition scopes. Fix the subtle issue where we'd do the
opposite for `group { ... }` syntax
Submit the tst_qqmljsscope changes that made the issue visible
Pick-to: 6.3
Change-Id: I314b19d5cad62f70146d228e5402c9fc73b309ad
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
As we deal with unsigned integer indices, there's no point in testing
them for >= 0 as this is always true. Apparently it is a -Wtype-limits
warning for some compilers
Change-Id: Ic5d633c2cc73f811f127f16f4d769d154364ccd0
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
We can transition to absolute indices (within the compilation unit)
from the relative indices we already have in each method and script
binding. Together with absolute indices, we also need to acknowledge
nested closures that some AST elements might have and so also store
nested runtime function indices along with the absolute ones
Absolute runtime function indices (and the nested ones) map to the
indices we store and use within the compilation unit at run time,
which are used to dispatch to correct JavaScript call during e.g.
binding evaluation - see QQmlEnginePrivate::executeRuntimeFunction()
Change-Id: Ieec58fbc36563511bd9763e358cda46c67757fa9
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Store relative (to scope) index for every Script binding and JavaScript
function into the corresponding data structure within QQmlJSScope. We
need this at a later phase in qmltc when code generating JavaScript
calls into the engine
For now, ignore the logic that converts the relative indices stored into
the indices pointing to the runtime function table
While testing the addition, observe missing cases where we do not record
bindings as such and fix that
Change-Id: I85030b7937c97f83183f88ae242af3a5f223443c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Extend group property binding creation with attached properties case
As a drive by, add extra attached property tests for QML and qmltc,
covering the case where an attaching type exists in both base and
derived types
Task-number: QTBUG-102082
Change-Id: I6c0d2b941da72d6dab7fc05a4f7b2a7875423ef0
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Cover the following case of binding on a group property:
Type {
group { foo: 42 }
}
Task-number: QTBUG-100168
Change-Id: I0147c74dffb649907457d5f17a2ab29473101a6d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Document (via test) what happens when we re-assign a group property in
the derived scope
Introduce a QML test module along the way used within the test
As a drive by, add all QML test files to TESTDATA
Change-Id: Id4c3e20e45b8e0f3757840c87e0285f8516319a8
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io>
Apparently we do that somewhere. It should not just crash.
Pick-to: 6.2 6.3
Task-number: QTBUG-102147
Change-Id: Id612e0543d8794aa4f334a899b117142b7a8cd38
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The factory should populate the pre-existing scope rather than copy it
into place. This way we can detect inheritance cycles involving the
pre-existing scope.
However, now we may detect the inheritance cycles earlier, when
resolving the types inside the lazy loading. We have the right pointers
available there now, after all. Therefore, add a way to propagate base
type errors out of the factory. When clearing the base type, we can now
give a reason for that. When checking the inheritance cycles we
retrieve that reason and log it.
We also remove the special casing of the ScopeType property of
QQmlJSScope. There is no real reason to set it in the ctor. As we
delay the population of QQmlJSScope now, we have to set it later.
Pick-to: 6.2 6.3
Task-number: QTBUG-102153
Change-Id: I49cf6e20f59fbdb6ed98a82040b3b159676f5975
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Still lacks support for merging and resolving grouped bindings, but
this will be handled in another patch.
Task-number: QTBUG-100168
Original-patch-by: Fabian Kosmale <fabian.kosmale@qt.io>
Change-Id: I1bb73f383acc3c8512676db47c5944f369b904b7
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Some classes (e.g. QQmlDelegateChooser) depend-on / inherit QmlModels'
functionality. We need to propagate that dependency to QML via qmldir
entry, otherwise we won't be able to see the types in QmlCompiler lib
Note that we already depend more strongly (via linking) on the
QmlModels library, so there is no reason not to depend on the QML
module in qmldir
Pick-to: 6.2 6.3
Change-Id: I4f16f66f2910fb6afd38475cd6ba3209cfd1207d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It does not seem correct to be able to use this function for both sides
of binding expressions: the property type and the assigned QML type
(`<property> : <qml type> {}`). Instead, it should really be a function
that considers both sides together (and actually checks the sides
differently!)
What we really should do for the assigned QML type is figure whether
its *first* non-composite base is a QQmlComponent - not just that it
is a QQmlComponent itself. Leave the QQmlAbstractDelegateComponent check
in place since this part is correct
The property itself, on the other hand, seems to cause an implicit
component wrapping if its type is QQmlComponent-derived (which means we
have to check the full C++ hierarchy)
As a drive by, also update QQmlJSScope::canAssign() since it used the
old function internally and was ignoring the case when a to-be-assigned
type lacks a C++ base type hierarchy (e.g. because it does not exist
ahead of time)
Pick-to: 6.3
Change-Id: I23524fa54d45d9140e1cafd9f81ef1f68d95f3a7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Makes sure we also look for suggestions in extension types. Adds two new
methods to QQmlJSScope called properties() and methods() to easily get
all of them across base types and extensions.
Change-Id: I5874c0221bac6d6e317b79146227bf749100f05b
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Anonymous imports are imports of QML types that aren't visible in the
current document. Internal imports are imports of C++ types, also
invisible, but potentially of the same names.
Before, types with exports were added to the qmltypes container using
their exports if any matched. If there were no exports, we constructed a
synthetic name and inserted that. However, as the nullptr example shows,
we need a reliable way to find them by their internal names, no matter
if exports are present. Therefore, we now consistently add them by their
internal names using the new $internal$ prefix.
Change-Id: I42ac2447cd924d09970c24554e1e2a5e631c5f79
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Do not expose this information to qmltypes just yet, though,
as this seems irrelevant at the moment
Pick-to: 6.3
Change-Id: Iffd8901ef9899a0fff226e8799bf45c1d688b92b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The default AOT compiler compiles QML code in indirect, dynamic mode. It
uses the logger's Log_Compiler category to determine the verbosity of
its output. In addition you can use the qt.qml.compiler.aot category for
even more verbosity. In preparation for using QQmlJSAotCompiler with
qmlcachegen, the default level of that category is increased to
QtFatalMsg. The highest level we actually output is QtDebugMsg, so it
doesn't make a difference yet.
If the logger's Log_Compiler category is set to produce errors, it will
qFatal() on "pragma Strict" violations.
Change-Id: Ieb74bfa7cd51cfa8616792ab467c32f6ba0e0702
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The compile passes shouldn't need to change the document, AST, or IR. At
least not accidentally. We might add interfaces to explicitly modify
things later. As a side effect, you can now use one instance of
QQmlJSTypeResolver for multiple documents by re-init()'ing it.
Change-Id: Ic3544b3ddedd30d7f8d00b1df9cee3e6292ca7de
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We want to be able to skip it.
Task-number: QTBUG-98305
Change-Id: Ibb0293d348f2828a28be4c458cf955b4cc706caa
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
... and give a hint on what to do about it. In order to not duplicate
all the warnings from the importer, make sure it runs only once.
Change-Id: Ie2b314ff659664f7c84c20cc7971c094e15c59cf
Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io>
UiArrayBinding stores object bindings for list<Type> properties (where
Type is, or is derived from, QtObject)
Test the change both in qmllint (with an ordinary "it reports warnings
when needed") and by introspecting QQmlJSScope. In the latter case we
can also ensure that the bindings are recorded in the correct order
Fixes: QTBUG-93358
Change-Id: Ib5544ba339e22ea899191483a5ba53f755314daa
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Make QQmlJSScope insert property bindings in the correct order.
We can do this by using some hackery:
- insert the element first through the QMultiMap interface
- query the non-const equal range and rotate first element to the end
The rotate is a bit slow, however, so let's do move left + copy-assign
Change-Id: I8f422c8a9105211fb016047c70b51b851c9873d8
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
There are already cases which couldn't be covered by qmllint (or qmltc)
Sometimes what we really want is a deep introspection into the type
hierarchy and the only solution is to exercise whatever things like
QQmlJSImportVisitor output
Change-Id: Ibe40249aec05f04b46c32466265ea704c35e70a4
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Ulf Hermann
Andrei Golubev
Sona Kurazyan
Maximilian Goldstein