Previous changes uncovered a problem with lacking of stdlib in
dependencies, which was quite hard to debug and determine.
So this check is supposed to discover similar issues in the future
much more easily.
Setting `linkViaSignatures = false` leads to the situation when fir2ir
provides no guarantees about how SymbolTable is filled, so if some
backend relies on symbol table content (JS and Native does) then
it's required to set this flag to `true`
The issue was uncovered by previous commits because previously fir2ir
created symbols with signatures for some declarations even with
disabled flag, which was fixed by those commits
This is needed to be able to implement creation of unbound symbols
for references of corresponding declarations (KT-62856)
There was an exception from FIR2IR that was fixed with this change,
so fir2ir test SuperClass started to pass along with IrActualizer,
which reported some new errors
This is needed to be able to implement creation of unbound symbols
for references of corresponding declarations (KT-62856)
There was an exception from FIR2IR that was fixed with this change,
so fir2ir test expectDeclarationWithWeakIncompatibilities started to
pass along with IrActualizer, which reported some new errors
Types based on type parameters which have both hasEnhancedNullability
and hasFlexibleNullability were incorrectly converted to IR: only
`@EnhancedNullability` annotation was added to the IR type. This means
that the nullability of the type started to matter, which is incorrect
because the type is supposed to be flexible.
This backfired in the IR fake override builder mode, where nullability
of methods inherited from both Kotlin maps and Java maps clashed, which
resulted in the exception from FakeOverrideRebuilder.
If the type is both flexible and enhanced, we're now adding
`@FlexibleNullability` to the IR type. Note that `@EnhancedNullability`
is not needed because it only affects primitive types which need to be
handled as wrapper types on JVM, but `@FlexibleNullability` already has
that effect.
IR still slightly differs from K1 for collection subclasses, which can
be seen for example in the changed IR text tests. This is to be
investigated later.
The change in tests is needed because the `kt48495*.kt` tests are now
passing on K2 in the IR fake override builder mode, while failing on the
vanilla K2.
This is related to KT-61370 but does not entirely fix it, although
curiously it fixes all remaining tests which were muted because of it.
Our Gradle integration tests could launch multiple Gradle daemons
with different versions and using different JDK versions. They are
stick around until the whole test finishes using necessary memory.
Especially this is a problem on our CI where OOM killer often tries
to kill actually needed daemon.
This commit decreases spawned Gradle Daemon idle timeout, so they
shut down itself much earlier than default timeout of 3 hours.
Checking the current applicability isn't enough because in the presence
of multiple diagnostics, the lowest applicability can be successful but
a higher one isn't.
#KT-63147 Fixed
A previous fix to the generator made the generator and checker
validation of classes which could be parcelized different. The checker
would report error in cases where the generator would not generate
anything. Align these checks, with improved code sharing, so errors are
not reported on classes which will not have parcelize components
generated.
^KT-63086 Fixed
This is to record the red->green change in behavior between K1 and K2,
when K2 correctly handles resolution/inference of an extension function
with definitely non-nullable type.
This still doesn't work for unresolved delegate (see analysis/low-level-api-fir/testData/getOrBuildFir/wholeDeclaration/localDelegatedPropertyWithPropagatedType.out_of_src_roots.txt)
^KT-63042
This leads to type ref referring to generic type variables being
serialized correctly.
When the type variable is declared on the member itself, it's written to
typeParameterName,
otherwise it's written to typeParameter. This is required for
deserialization to work correctly.
#KT-63227 Fixed
The relative path of a test file is just its name, even if it's in a
module.
Diagnostics in IR are mapped to the file path and so it's reported on
all files with the same path, i.e. name.
This doesn't happen in production code because no two files can have
the same path.
The proper fix would be to prefix the test files' paths with the module
name.
Unfortunately, this breaks a bunch of test runners that rely on the
current behavior.
Especially, some JS runners turned out to be hard to fix.
The linked YouTrack issue contains a WIP, incomplete patch of fixing
some runners.
#KT-61592 Fixed
#KT-63252
Ivan Kochurkin