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