Keep them in a special generated struct with virtual method that gets
called from the GC for each frame.
Pick-to: 6.10 6.9 6.8
Fixes: QTBUG-139059
Change-Id: I81bcbeab6531e174a5207d03f57d241461ae9ba3
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
While the Sequence is detached it is subject to the GC or
unrelated C++ code deleting objects from its internals. Since it's then
not the owning object's responsibility to track this anymore, we need to
track it ourselves. The way to do it is to use the existing V4 objects.
We don't have to store the sequence on the JS heap if it cannot store a
QObject. Only lists of variants or pointers are affected.
This independently fixes QTBUG-129972 for 6.8 where
VariantAssociationObject does not exist, yet. This is because the
detached sequence shown in that bug won't need to be written back to
anymore in order to stay up to date.
Pick-to: 6.10 6.9 6.8
Fixes: QTBUG-129972
Task-number: QTBUG-139025
Change-Id: Ib469c6c65f2f96041e2ad2fd106f8cd60a182e13
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Without this, it tries to resolve the metaObject of QVariantMap, which
crashes.
Fixes: QTBUG-139626
Pick-to: 6.10 6.9 6.8
Change-Id: I9248f57c428810024f9983df959f475e6557576c
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
While the VariantAssociation is detached it is subject to the GC or
unrelated C++ code deleting objects from its internals. Since it's then
not the owning object's responsibility to track this anymore, we need to
track it ourselves. The way to do it is to use the existing V4 objects.
Pick-to: 6.10 6.9
Task-number: QTBUG-139025
Change-Id: Ic1d5aa85171b5d91c2b9d546963268b6f09c2802
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Component.onDestruction can be used to execute some code as an object is
being destructed. The code may, however, reference objects that are no
longer in a valid state because they themselves have already been
destructed. We then throw an exeception.
Commit a741271dd5 introduced the init step
for calls in which the types of arguments are resolved. For object
methods, we need to check that the object is still valid or throw an
exception otherwise. This is made more complicated by the fact that, in
some cases, the destruction of the object happens in a somewhat chaotic
manner where, for instance, the object is still alive but its method and
property storage has already been deleted.
This inconsistent state is the cause of QTBUG-138516 and existing checks
for invalid objects were not sufficient and we crashed when trying to
use the function that we were unable to resolve. We can detect this
particular problem by checking whether the ddata of the object still has
its jsWrapper.
Amends a741271dd5
Fixes: QTBUG-138516
Pick-to: 6.10 6.9
Change-Id: Ifdd7708d73ea6012d1e07aebed257b3f538183c1
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Flags declared with Q_FLAGS lack the methods for properly extracting the
typedef'd name. We need to manually register the typedef.
Amends commit 8bf5aae19b.
Pick-to: 6.10 6.9 6.8
Fixes: QTBUG-138174
Change-Id: I7c373f4d810a0c9a5590f39cc629015662a69ed4
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
When trying to resolve all aliases on an object, we iterate over them
one by one. If all are resolved successfully, we return
AllAliasesResolved and consider this object done, if an alias fails, we
return NoAliasResolved or SomeAliasesResolved and we will try again
later. This can be the case for aliases to aliases. We defer resolving
the first one until the target alias is resolved first.
There was a bug in the logic that counts how many of the aliases were
successfully resolved and how many were skipped. When skipping an alias
to an alias, we cannot count it among the completed ones.
This leads to an alias not being resolved and added to the property
cache. Thankfully, a runtime assert then catches the discrepancy between
the number of aliases in the property cache and in the compilation unit.
Early exit when detecting that the alias points to a non-local
unresolved alias to try again later. Also update the aliasIndex as part
of the for loop update.
Amends 9e1378260a
Pick-to: 6.10
Change-Id: I6ee7a796a0b4890393d5b17ebea2686c55955394
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Now that we discern internal and external side effects, we cannot
implicitly rely on every jump to generate a side effect anymore. We need
to actually update the virtual registers and also merge the side effects
(along with other flags).
Amends commit 6b14ba5c2f
Pick-to: 6.10 6.9 6.8 6.5
Task-number: QTBUG-137540
Change-Id: I6b46c7a4773759c8f6f30308ba72082555ce3e61
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
inlineConsoleMethod's stringConversion needs to create a string, so that
we can later append to it. Because we were missing parentheses, this did
not happen, and we would end up with code looking like
u']'.append(...)
which obviously isn't valid C++. Fix this by always adding parentheses
around the expression.
Found while trying to prove that QTBUG-109279 was fixed.
Task-number: QTBUG-109279
Pick-to: 6.10 6.9
Change-Id: I67fce5b2c1f1460a5d6b617824f3c36f9804ea76
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
A mere jump does not cause all value types and lists to be invalidated.
Only calls to other functions or writes to other properties do that.
Pick-to: 6.10 6.9 6.8 6.5
Fixes: QTBUG-137540
Change-Id: I069c6873455c51bbea59cf876d2bc7ecd188f81b
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
Stack-created lists of primitives or pointers cannot be affected by side
effects. We cannot write a value affected by side effects to a list that
isn't, though.
Pick-to: 6.10 6.9 6.8 6.5
Task-number: QTBUG-137540
Change-Id: I99ab4337cabc6111a81b8164fd94962edc0db25e
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
We use the JavaScript extension as "read" type to signify that the code
generator will accept any type with such an extension. This requires
some adjustments in the type resolver.
Pick-to: 6.10 6.9 6.8 6.5
Task-number: QTBUG-137540
Change-Id: Ia34ca0a24c417c5372852268ba2f55825484639d
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
[ChangeLog][QML] It is now possible to access unscoped enum values in a
scoped way as <component name>.<enum name>.<key>. Previously, it was
only possible to access them in an unscoped way.
Task-number: QTBUG-116513
Change-Id: Iff56cd3365516215e1e195a147fae66ee17d39e3
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
In the type propagator, when encountering back jumps, we need to run the
pass again in order to ensure that the state of the registers at the
target of the jump is fully known.
For this, we need to compare the latest state in the current pass with
states we have encountered earlier. If a match is found, no more passes
are needed.
The propagation is run multiple times and state is accumulated between
passes. For certain conversions, this will try to append types as
origins again every iteration. These would previously have been
deduplicated by QQmlJSTypeResolver::merge but, since the change at
1e095058e1, we consider 2 registers to be
equal only if their d pointers are equal. And since instructions such as
MoveRegexp create a new register for the literal type RegExpr every
time, the pointer doesn't match with the one from the register created
by the instruction during the ealier pass. This would lead to set of
origin types growing forever and to the state never matching a previous
one. This, in turn, caused an infinite loop because an additional pass
was always deemed necessary.
Therefore, restore the old logic that deduplicates based on contained
type, variant, and (recursively) scope.
Amends 1e095058e1
Fixes: QTBUG-135457
Pick-to: 6.9
Change-Id: I23167e95b958304698d12537598c1d72b03a5364
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
There is nothing to do in the compiler.
Setting the value of the property is already handled in by the object
creator or the qobjectwrapper.
Reading the value doesn't really makes sense and defeats its purpose .
Fixes: QTBUG-134790
Pick-to: 6.9 6.8
Change-Id: I4576eb528e0dec273830b0244149a92ceb325bc9
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
We already do this for return types, but it's fatal on any type.
Pick-to: 6.9
Fixes: QTBUG-135342
Change-Id: I7aee2a19ffcd39d2707eceb34b5073057d8b5ebb
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
If we can determine that the base of an optional lookup cannot hold null
or undefined, we can simply omit the optional part and generate a
regular get lookup. This is also true whenever we lookup an enum.
Amends fc4ee77116
Fixes: QTBUG-135649
Pick-to: 6.9 6.8
Change-Id: I64984fdecc75cd4dbc2274a08aa73b5274fb09b7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
We've resolved the value type in the type propagator. Trying to do it
again in the code generator, after the iterator may have been adjusted,
is quite wrong. If we resolve the list value type on a type that's not
a list (anymore), then we get an invalid type, which subsequently
crashes.
Amends commit a173d50a9e.
Pick-to: 6.9 6.8
Fixes: QTBUG-135288
Change-Id: I1227803ed100c83f8fc11898be0a4d0199d639dd
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This works the same as the FINAL attribute to Q_PROPERTY.
Task-number: QTBUG-98320
Change-Id: Icc2cf1afb5354fd711770f7147ded853b74cd1da
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Those have several possible representations. Besides
QQmlValueTypeWrapper, they can also be their own special heap objects
with extra methods, or VariantObject.
Also, remove some pointless restrictions in QmlCompiler that prevented
such as-casts from being compiled to C++. The code generator will
currently reject non-trivial type assertions for value types. Therefore
we don't have to take care of ValueTypeBehavior: Assertable, yet.
Also fix tst_qqmllanguage::instanceOf() to actually test something. So
far the return value of the expression was ignored for most data tags.
Pick-to: 6.9
Fixes: QTBUG-130291
Change-Id: I2facf48455a04a02a078615e5ebd4b1c26d1bd93
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
We need to perform the redirection before inserting imports into
namespaces. Through the redirection we might discover a module that we
have already imported before. In that case we must not import it again.
Pick-to: 6.9 6.8
Fixes: QTBUG-133587
Change-Id: I47a279461763b5397137002a9e7c7d3bfc7ad15d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Those are not mapped to regular QMetaMethods but rather come with
special method indices and need to be resolved separately.
Amends commit a741271dd5
This exposes that the override order between JavaScript extensions and
their base types was wrong. JavaScript extensions do certainly not
override their base types. Fix this, too.
We also need to always specialize the lookups for these calls. It
doesn't actually matter if there is propertyData or not since we branch
off into the special cases anyway when calling them.
Pick-to: 6.9
Fixes: QTBUG-132602
Change-Id: Iea83ce94459b0d0a3bf54731898fd62b9ad46c46
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
While those properties may be of type Component, they don't have to. We
can in fact not resolve anything resembling an ID while inside one of
those objects because we cannot determine the component boundaries.
Amends commit dea8e38d95
Pick-to: 6.9 6.8
Fixes: QTBUG-133460
Change-Id: Iac7294166d38ce591c45c0d31b139a52eda70fc1
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
The actual conversion code suggests that we may be creating a shared
list property. However, the assignment code internally won't let that
happen. Test as much.
Amends commit 3108c58b97
Task-number: QTBUG-133047
Change-Id: I66f0f043e0dabd2693aa50a30478461a5db5c5ad
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
At run time, not all the builtins are always available, but only those
hardcoded into the parser. If we always import all the builtins at
compile time, we introduce subtle errors when they shadow parts of the
JavaScript global object.
Now the builtins need to be actually imported. We cannot rely on the
magic that adds them to the root scope of each document anymore. To this
end, they need to become a regular module.
The builtins are now loaded using a qmldir, just like any other module.
The only thing special about is its "system" attribute which we now
take to mean "read jsroot.qmltypes". Furthermore, the builtins get a
"static" attribute so that we don't warn about them being unused. Even
though they can now technically be unused, we really want people to
still import them.
Pick-to: 6.9 6.8
Fixes: QTBUG-133461
Change-Id: I322e14ba85c939773d36143ca24e88a7c9db23f5
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
The comparison code was generated properly but the conversion to safely
assign the result of the comparison to the out accumulator was missing.
Amends 78b58582ba
Fixes: QTBUG-133636
Pick-to: 6.9 6.8
Change-Id: I9f790b449b48c382064954ad4235d25d221f1168
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
We have the same conversion code already for lists of value types and
JavaScript arrays. Specialize the common cases of QObjectList and
QQmlListProperty<QObject>.
Pick-to: 6.9 6.8
Fixes: QTBUG-133047
Change-Id: I10826d4a965e18471a486e19befef961ec9a4a6e
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
Before the refactoring of callObjectPropertyLookup and
initCallObjectPropertyLookup this was done via a check on the resulting
function. This check is in the init method now. However, after
initialization, you can still call the (pre-resolved) method on a nullptr.
Therefore, we need a second check.
The method counts as pre-resolved even if we re-fetch it due to a
variant lookup. We can be sure that there is some method in that case
after all.
Amends commit a741271dd5
Pick-to: 6.9
Fixes: QTBUG-132499
Change-Id: Idb8c50f3698c5502cf2e8116e6341ef1a537bc64
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
Since it's documented like this, we should actually allow it.
Pick-to: 6.9 6.8 6.5
Task-number: QTBUG-132118
Change-Id: I2192f040b8fdf545b8dbb0687b6e618a9858ed07
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
The regular int32 coercion doesn't apply here. We have our own logic for
this case.
Pick-to: 6.9 6.8
Task-number: QTBUG-132345
Change-Id: I96596567ce83fcaa714c8372171261e8dd876480
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The conversion is not required to produce the same type. It can also
produce something equivalent that holds the same value. For example an
integer of a different kind that on assignment gets C++-converted.
Pick-to: 6.9 6.8
Task-number: QTBUG-132345
Change-Id: I07accb38062b7c89ab60d50bf6cbd63423e68301
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
It's not necessary anymore. We can use the read register as-is. Also,
explicitly name the type we are going to use to avoid integer range
mismatches on coercion.
Pick-to: 6.9 6.8
Task-number: QTBUG-132345
Change-Id: I98d246b03e5194235246ee8e4ebcb0a8e0094a5b
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
The type of the register may not be the one to be passed to the method.
We cannot rely on the run time internals to coerce the value anymore
since we've moved the type determination out of the generated code.
To make this happen, we need to adjust the storage types of read
registers in the storage generalizer.
Pick-to: 6.9
Fixes: QTBUG-132329
Change-Id: I642027f349f7c05f714ec36ef4e23f9d59b4a8df
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
Now that Pane reflects its explicitly set contentWidth/Height through
implicitContentWidth/Height we can use the same expression for implicit
width/height as regular controls, which hooks us into the safe area
binding loop detection as well.
Pick-to: 6.9
Change-Id: Ie31b740a1e405341fc5f0ed9673b213292e4afd9
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
When constructing a value type, we cannot just assume that the
most-derived type holds all the properties. We may encounter properties
from base types. Resolve those via QMetaProperty.
Pick-to: 6.9 6.8
Fixes: QTBUG-131980
Change-Id: I8e1773ccb42f86b96457c990ae5bc6486ae1acdc
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Define a pair of lookup methods for this and generate code that uses
them. Write back after calling a non-const method.
Task-number: QTBUG-127174
Change-Id: I6de22e76b63390fd7159d9c14ea2c908d961ec97
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
With SetLookup there is always the possibility of causing a reset by
passing undefined. That's why we need to wrap the argument into QVariant
most of the time. SetValueLookup didn't take this into account, which
resulted in invalid code.
The test also reveals that a number of cases were generating different
errors depending on whether the code was run in interpreted or compiled
mode. Align those.
Pick-to: 6.8
Task-number: QTBUG-127174
Change-Id: I88f45977dcd0eeba8aaf580663d4b85b8bb26f72
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
On the engine side, types made available with QML_USING are recognizable
by their QMetaType conversions. In order to actually call the right
methods, we need to slightly prefer methods to whose arguments we can
convert over ones we have not idea about. This, however, adds the
problem of converting to QString, double, QVariant and QJSValue, which
is possible for any type. Since such conversions are less specific than
manually added converters, we de-prioritize them a bit.
On the compiler side we need to transmit the knowledge about the
overload to be called from the compiler (which has already done its own
overload selection) to the lookup methods. This is easily done using the
relative method index. This way we do not need to do any run time
overload selection at all and we do not need to pass any types to the
lookup methods. We can do this without further compatibility adaptations
because the current version of those lookup methods was only introduced
in 6.9.
Excluded, of course, are shadowable calls, which are performed with only
QVariant arguments. These carry the arguments themselves and trigger the
engine's overload selection. Internally nothing changes about them.
Passing a list of QMetaType::fromType<QVariant>() to the lookup methods
for them has always been a waste.
Only the engine changes are relevant for 6.8. In 6.8, the lookup methods
defer the overload selection to the engine and take the types on every
call. We still cannot separate the engine changes from the compiler
changes in dev because the same test is run once in interpreted and once
in compiled mode.
Pick-to: 6.8
Task-number: QTBUG-127174
Change-Id: I6ab52ddf3be65dcc94547266c5dcc5ac1050c93c
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
qmlcachegen will never generate code that calls these with mismatched
types. Checking the type at run time is wasteful. With QML_USING, you
can make qmlcachegen generate code with types we cannot recognize as
compatible. However, those need to be layout-compatible so that they
can be reinterpret_cast'ed into each other. If they aren't that's a user
error in C++. We can crash on such a thing.
However, in StoreNameSloppy and in the variant lookup cases, we do need
to convert types. Since the QML_USING type conversions are unknown to
the QML engine, we have to provide a fallback via QMetaType::convert()
here. So, despite the layout compatibility requirement, the QML_USING
types also need to register metatype converters before any QML code
accesses them.
As a result QML_USING has quite a few complicated requirements now and
is _really_ dangerous.
Pick-to: 6.8
Task-number: QTBUG-127174
Change-Id: I1b8e1595e3088415ce711e910586a5dd456cb2c5
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
This allows us to create value types with invokable copy ctors from
JavaScript objects that describe their properties. That way we now have
a full replacement for the Qt.foo() methods.
As a side effect, we support retrieval of enums for certain kinds of
broken value types now, if prefixed with a namespace.
Fixes: QTBUG-124634
Change-Id: If2a3c59d647e211ef5a0cd1ddee04b409d9ea5f3
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
All reference objects should be detached when written to a property of
a QML-defined type. This is in line with what happens if you write the
same object to a property of a C++-defined type and doing anything else
makes very little sense.
In particular, before this change, the behavior differed between
ahead-of-time compiled code and interpreted code, between writing to
"var" properties and writing to typed properties, and between different
kinds of lists. Now everything we recognize as reference object always
gets detached when writing to a property.
[ChangeLog][QtQml][Important Behavior Changes] Writing a list or value
type to a QML-declared property now always detaches this same list or
value from any locals or other properties you may have read it from.
Therefore, subsequent changes to its "source" will not affect it
anymore. This is in line with what we do to C++-declared properties.
Fixes: QTBUG-127957
Change-Id: Icdf188ef29d28e5d3aaa8219cc003e07e8813f38
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
You can QCOMPARE a QString to a unicode literal, but if the comparison
fails, it cannot print the result.
Change-Id: Iceea7074ecb893bc0c514d3b872e33b786edac84
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Now that resolving the types can be more expensive, especially for
composite types, we should be careful not to do it too often. Most of
the cases where we have to resolve types are for lookups. Most of the
lookups only resolve types in their "init" step, which ideally is only
performed once in the application life time.
However, so far calls had to pass the types of arguments and return
values in the actual "lookup" step, which causes the resolution to
happen on every call.
This change moves those type resolutions to the init step. We can do
this because:
1. Regular typed method calls are calls to a specific overload with
specific types. The method itself already has the list of types and
we can just remember which one that is. Then we don't need to pass
the types.
2. Calls to shadowable methods are all-QVariant typed. The only thing
we need to know is the number of arguments. Then we can construct
the list of types in the lookup itself.
We can remember which one of those we're dealing with by adding further
"AsVariant" lookup functions. For the case of non-property-cached
regular methods we also need a new "Fallback" lookup like we already
have it for properties.
Change-Id: I74a3729131d6a5ea0ad79e276965a5167cd609be
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
This should help find raw string literals in generated code
Task-number: QTBUG-129797
Change-Id: I66e5d6302319678b494030e8cb3459eb06f0f134
Reviewed-by: Semih Yavuz <semih.yavuz@qt.io>
So far we produced invalid QMetaTypes for them in various places and
that "worked" for the most part because with QObject pointers we can
introspect the actual type at run time.
Realize that we never actually want the concrete anoymous type of the
object when we pass it around. Rather, all methods and properties need
to handle named types. What we really want to resolve is therefore not
the type of the original value we've produced in the type propagator,
but rather the replacement we've produced when analyzing the lookup.
Pick-to: 6.8
Task-number: QTBUG-129202
Change-Id: I0b93495d6603f120375048c80a747170f147f8af
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Olivier De Cannière <olivier.decanniere@qt.io>
(cherry picked from commit 14ff6822a0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The metatypes from any old engines may have been deleted.
Retrieve the types from the ResolveTypeReferenceMap instead. That is
much cheaper than doing a full type search and the CU should know the
types it's dealing with.
Sometimes, however, the CU does not pre-resolve the types. In
particular, types only used in function signatures do not end up in the
ResolvedTypeReferenceMap. In those cases, still do the full type search.
Amends commit 8bf5aae19b.
Pick-to: 6.8.0 6.8
Task-number: QTBUG-129388
Change-Id: I27f25e1c68de3c752d00345c6d94016fb315e16c
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
If we cannot resolve a type, we need to assume that all its properties
are components and assign separate contexts to all inner objects.
Otherwise, if one of them actually is, the attempt to resolve it at run
time will crash.
Pick-to: 6.8
Fixes: QTBUG-129281
Change-Id: Ic34b5308accdd93f6797ee39fcd56040cf86b1ce
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
If we cannot properly resolve the types we should still set the
accumulator to something so that the type propagator can continue.
Amends commit 6a2308e500
Change-Id: Idf3d093ca877bcf11f6a9a82a9d01ccead19e2cc
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Ulf Hermann
Olivier De Cannière
Fabian Kosmale
Tor Arne Vestbø