The new inference uses inferred intersection types normally, unlike the old inference.
However, intersection types in public declarations are approximated to supertype, which
potentially may give a less presice type, then it would be with the OI.
For non-related T1, T2 the NI approximates {T1 & T2} to Any in public declarations,
and if the OI was inferring T1 instead of the intersection type, it may lead to
less precise declaration type and related errors.
The solution is to remember an alternative for an intersection type when present.
Before approximation the alternative replaces the intersection type.
^KT-36249 Fixed
Using different incremental setting for KotlinCompile makes impossible
using caches built on CI since it is marked as @Input. Same property for
JavaCompile marked as @Internal.
We do clean checkout now so it shouldn't matter but we want to build
incrementally in some cases for Dev builds on CI.
Compiler version changes every build and makes impossible to reuse
caches for heavy tasks such as compiler proguard. We may fix that by
adding version module directly to the final jar.
Writing build number into a public constant field leads to poor gradle
cache reuse between different builds. Public constant value is a part of
public api and its changes affect inputs of dependent modules.
Extracting build number to resource file allows to ignore it from
runtime classpath which fixes same problem for KotlinCompile tasks
This seems to be the only reasonable way to provide function declarations with
_correctly_ substituted type parameters without rewriting logic from scratch;
correctly scoped type parameters in IR are now required in serialization
plugin by all backends.
Also fix some missing upper bounds.
It turns out that `jvmTarget` and `javaHome` settings in
build.gradle.kts were changing the module settings and affected the
compilation of kotlinx-metadata-jvm sources. The correct way to use JDK
8 in tests would be to change JVM target / JDK home of the specific
KotlinCompile task via its `kotlinOptions`, but JarContentTest doesn't
need JDK 8 anyway at this moment, so simplify that instead.
They are inline-only.
Generate $$forInline versions of inline suspend functions as private.
This way, there is no nullability annotation on there parameters and return
values. Unfortunately, old BE does generate them.
#KT-37088 Fixed
Pavel Kirpichenkov