Expect declarations do not survive serialization to KLIB. So they need to be explicitly filtered in order for tests that compare dumped IR before and after serialization to pass successfully.
^KT-61136
Added a new FIR based checker for both FINITE_BOUNDS_VIOLATION and
FINITE_BOUNDS_VIOLATION_IN_JAVA errors. Implementation copied from the
existing descriptor based checker with some minor changes.
#KT-59378 Fixed
We expect that some configurations might fail to resolve in the case of
stdlib-js dependency if they are resolved explicitly. These configurations
should not actually resolve for the KGP user.
^KT-60901
^KT-61126
This will prevent transformed kotlin-stdlib source sets from
being resolved for leaf (e.g. jvmMain) as well as bamboo (jvmBambooMain)
source sets. For such source sets only the jvm jar shall be attached
^KT-60901 Verification Pending
This change is required to fix stdlib compilation with enabled
linking via signature. All primitive iterators are considered to be
builtins and are created during compile time as deserialized
declarations (at least in K1). But if we meet the definition of some
primitive iterator in code, for example, during stdlib compilation,
we will end up with two different descriptors (deserialized and lazy)
that describe the same entity. Because of that we have conflicts in
symbol table:
* For descriptors, we will end up with multiple IR declarations
that describe the same class, but with different descriptors. With
some magic compilation still works.
* For signatures, we will end up with only one IR declaration in the
table, but it will have wrong deserialized (instead of lazy)
descriptor.
In the end, this change allows us to initialize iterators in advance
with correct descriptor.
#KT-56230
CompareDistributionSignatures task is used to compare Native platform
libraries contents against a previous version.
Under the hood, it runs the klib tool to get a library contents. But it
didn't check the exit code, so if klib tool failed, the task could
mistakenly indicate that there are no differences in platform libs.
Fix this by checking the klib tool exit code and failing if it is not
zero.
Let ConeCompositeConflictResolver pass the results of the previous
resolver to the next one.
Otherwise, we get false positive conflicts when a set of candidates
can't be fully reduced by one resolver but could be resolved by the
subsequent application of multiple ones.
This change makes ConeCompositeConflictResolver order-dependent and
thus, ConeOverloadConflictResolver must be invoked last, because it
must work on a pre-filtered list.
Also, let ConeEquivalentCallConflictResolver use
FirStandardOverrideChecker instead of compareCallsByUsedArguments
because it's stricter.
This all fixes a false positive overload resolution ambiguity in common
metadata compilation that is caused by stdlib using the new KMP
format.
Now stdlib metadata is in the classpath, and so declarations from the
stdlib are returned from both MetadataSymbolProvider and
KlibBasedSymbolProvider.
This isn't a problem per se because duplicate candidates are filtered
out by ConeEquivalentCallConflictResolver (K1 works analogously), but
in the case of top-level functions with generic receivers like
Collection<T>.toTypedArray, the check failed because of the direct
comparison of receiver types.
#KT-60943 Fixed
- Mention link to docs about templates in warning messages
^KT-60491 Fixed
- Make sure that each warning mentions some way to solve the problem
aside from disabling default template
- Fix small syntactical bug in code sample
- fix incorrect indentation in trimMargin after joinToString
- Use kotl.in in Kotlin12XMppDeprecation
Dmitriy Dolovov