The data structure version is supposed to encode any incompatible
changes to our compilation unit format. Checking the compile hash and Qt
version in addition is redundant and excessively restrictive.
[ChangeLog][QtQml] You can now use QML code compiled with Qt Quick
Compiler across Qt versions as long as the compilation unit format
hasn't changed between those versions. You cannot rely on the
compilation unit format to stay unchanged under any specific
circumstances. However, we won't change it unnecessarily.
Change-Id: I8c407b505ac7fa952f53fa25bb6d4e7caf0fba0c
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
If a compilation unit for the given URL already exists in the type
registry, we can safely use it since anything in the type registry is
shareable. An exception to this are requests with explicit inline source
code. Those cannot be cached at all.
Conversely, if we were to re-compile, that's not only wasteful but we
may end up with diverging type hierarchies and mismatched types.
Revert commit d0e16e3f61 since it has
become counter-productive now. We really want to have exactly one base
compilation unit for each type, and that should be universally
accessible. When d0e16e3f61 was written we
had separate base CUs for each engine, and we didn't want those to
accidentally find each other.
Realize that composite types have to be indexed by url(), not
finalUrl(), since url() includes any file selectors while finalUrl()
does not.
Fixes: QTBUG-134398
Pick-to: 6.9.0 6.9 6.8 6.8.3
Change-Id: I130cdc27ebd8a2814e194478a27eef5bb7f79eb7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
A (base) compilation unit should ideally be immutable, as we otherwise
open a can of worms when it comes to cross-thread usage of CUs. However,
so far, we've been using a mutable inlineComponentName member of the
compilation unit to select whether the root component of a CU should be
constructed, or one of its inline components.
This patch change prepares for making the CU immutable, by moving the
inline component name tracking into the ObjectCreator itself, requiring
that the name gets passed into its constructor – or that an empty string
gets passed in case of the main component.
The resulting refactoring makes it apparent that deferred properties
did not handle inline components at all. Support for them gets added by
also storing the inline component name inside of DeferredData, and
passing it along when needed. A test case which verifies that deferred
properties are now fixed is added as a follow-up commit.
Besides the core engine, we also need to adjust qmltc which also
generates code to handle deferred properties. Consequently, we also need
to pass the inline component name along in the qmltc generated code.
Task-number: QTBUG-131442
Pick-to: 6.5 6.8
Change-Id: Ide9bc98223c01225b954662b3f4989bbbfda7672
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
There is nothing that makes it depend on ExecutableCompilationUnit.
Change-Id: I482dfc0177530f748bb90e5373c64ca5558d8629
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We rarely actually need the executable CU, and where we need it, we can
dynamically create or retrieve it from the engine. To that end, store
all the CUs in the same container in the engine.
Change-Id: I0b786048c578ac4f41ae4aee601da850fa400f2e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It only exists so that the type loader can query pre-compiled and native
modules from the loader thread. However, the type loader already has a
mutex of its own. We can use that to inject a "native" blob into its
script cache for the same effect.
We need to get rid of the mutex so that we can use the module map for
other compilation units, too.
Change-Id: I5a9c266ea36b50f5ea69214110def644f7501674
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We don't want floating unlinked executable CUs. They should always be
tied to an engine, and the engine should not change. This gives us one
definite point where to register them with the engine (to be done in
subsequent change).
Unfortunately, due to the refcounting, we need to remove the engine from
any still-referenced CUs when the engine itself is destructed. We will
be able to drop the refcounting and make the engine fully own its
executable CUs once we can hold base CUs in most places.
Change-Id: I9a53e83d5c4746c2b2bca896b51baa4fe7fee757
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Ulf Hermann
Fabian Kosmale