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
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
When there are two candidates for a Java method to be interpreted as a
getter for inherited Kotlin property, one from current class, another
from supertype, create just one JavaForKotlinOverridePropertyDescriptor.
Case in point: java.lang.Hashtable.
While we have an overload resolution algorithm working for O(n^2),
call resolution for the single particular call may work more then just
a second.
Thus, we need to call ProgressManager.checkCanceled() with more granularity
^KT-35135 Fixed
See 62a55b7b00
Previously, it was working for O(n^2)
Now, we first group it by jvm descriptor,
then for each groups of size g_i finding the most specific for O(g_i^2)
It should help for the cases when we have a lot of overloads with
different JVM descriptors (modulo return type)
NB: Having the same JVM descriptors is rather rare, because
in Java one cannot generate such a class.
Looks like it's only possible for Scala or some other JVM languages (KT-17560)
It should help a lot for KT-35135
- Remove klib dependency on metadata and uniqID
- Refactored proto format to make it more effective and compact
-- Use special encoding for some types of data (coordinates, flags, types)
-- Remove symbols table
-- Use packed proto list if it is possible
- Remove extension from metadata
- Remove special ids for function interfaces
- Fix klib IO
- Fix incremental cache
- General code clean up
From now on, the old JVM backend will report an error by default when
compiling against class files produced by the JVM IR backend. This is
needed because we're not yet sure that the ABI generated by JVM IR is
fully correct and do not want to land in a 2-dimensional compatibility
situation where we'll need to consider twice more scenarios when
introducing any breaking change in the language. This is generally OK
since the JVM IR backend is still going to be experimental in 1.4.
However, for purposes of users which _do_ need to compile something with
the old backend against JVM IR, we provide two new compiler flags:
* -Xallow-jvm-ir-dependencies -- allows to suppress the error when
compiling with the old backend against JVM IR.
* -Xir-binary-with-stable-api -- allows to mark the generated binaries
as stable, when compiling anything with JVM IR, so that dependent
modules will compile even with the old backend automatically. In this
case, the author usually does not care for the generated ABI, or s/he
ensures that it's consistent with the one expected by the old compiler
with some external tools.
Internally, this is implemented by storing two new flags in
kotlin.Metadata: one tells if the class file was compiled with the JVM
IR, and another tells if the class file is stable (in case it's compiled
with JVM IR). Implementation is similar to the diagnostic reported by
the pre-release dependency checker.
The Android build pipeline can extract embedded proguard configurations
from dependencies and merge them automatically. This adds a conservative
proguard configuration to the kotlin-reflect JVM artifact in support of
that. This focuses mostly on just retaining what's necessary for
kotlin-reflect's own functionality to operate, but could be expanded if
community feedback discovers other good candidate rules.
With this in place - most Android projects using R8 or Proguard should
Just Work™️ with kotlin-reflect.
Georgy Bronnikov