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
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
This helps to completely get rid of Visitors API during reading and writing
of the JVM metadata.
Note: Klib writers still use .accept and left for future refactorings.
See also #KT-59442
Rewrite Readers.kt and Writers.kt to avoid using
Visitors API
Align KotlinCommonMetadata/KotlinModuleMetadata API with
KotlinClassMetadata one (it is necessary for restructured reading/writing)
#KT-59442 In Progress
This fixes an issue where the opt-in annotation is defined in one of the
source sets of the compilation but opt-ins are defined for the whole
compilation which leads to false-positive "Opt-in requirement marker is
unresolved" in (e.g. common) source sets that don't have a dependency on
the module that contains the annotation.
#KT-60755 Fixed
Now the multiplatform extension exposes compiler option DSL for common
compiler arguments. This compiler option synced as a convention for
targets compiler option.
In the case of Kotlin source sets which are not used as defaultSourceSet
in compilations - extension compiler options are synced as convention
into those.
^KT-57292 In Progress
Experiments with the DefaultKotlinCompilationAssociator where made
during KT-60937. One experiment broke running functionalTests in
kotlin.git in bootstrap mode. This case was not yet covered by
CI.
^KT-60937 Verification Pending
As it might happen, that the configure code could be triggered
too early, capturing the state of 'runtimeDependencyFiles' to early as well.
^KT-60937 Verification Pending
The IdeBinaryDependencyResolver will filter respective
files by using a simpler check: testing if the files
do reside within the build dir of the current project.
^KT-60937 Verification Pending
Sebastian Sellmair