In JVM IR, both `valueParameters` and `isFromJavaOrBuiltins` take
noticeable time (1% of all compilation) because the logic for these in
IrBasedDescriptors is not trivial.
Don't mangled functions annotated with @JvmName.
Annotate 'Result.success' and 'Result.failure' with @JvmName and
@Suppress("INAPPLICABLE_JVM_NAME").
NB this would require bootstrap.
Since 1.4.0-dev-8774, we mangle functions returning inline class values,
including functions with return type 'kotlin.Result'. This causes
incompatibility when 1.4 compiler is used with 1.3 (or just some
pre-1.4.0-dev-8774) standard library.
Also, write "message from the future" on functions returning inline
class values indicating that they can be used since compiler version 1.4
(otherwise 1.3 compiler using 1.4 stdlib would fail to find some
@InlineOnly functions such as 'Result.success' and 'Result.failure').
Instead of generating these annotation classes as package-private on
JVM, serialize their metadata to the .kotlin_module file, and load it
when compiling dependent multiplatform modules.
The problem with generating them as package-private was that
kotlin-stdlib for JVM would end up declaring symbols from other
platforms, which would include some annotations from package
kotlin.native. But using that package is discouraged by some tools
because it has a Java keyword in its name. In particular, jlink refused
to work with such artifact altogether (KT-21266).
#KT-38652 Fixed
This has no effect currently because all class files produced by Kotlin
have the bytecode version in the metadata (currently 1.0.3).
However, this change will allow us to stop writing bytecode version to
metadata in Kotlin 1.5. In fact, we could do it while the default here
was INVALID_VERSION too, but then for example compiling with Kotlin 1.3
against binaries of version 1.5 would lead to extraneous "incompatible
bytecode version" errors (because INVALID_VERSION is basically 0, which
is incompatible to 1.0.3+), in addition to the correct "incompatible
metadata version" error.
The reason why we might want to avoid writing bytecode version is the
fact that the initial use case it was added for is already supported by
the metadata version, and the bytecode version error reporting was never
fully implemented. Actually bytecode version was almost unused because
of that.
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.
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
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.
* JVM incorrectly mapped T<KClass<...>> to T<Class<...>> because the
annotation-ness of the type mapping mode was inherited one level
down into a generic signature independent of T
* JVM_IR was even worse as it did not use VALUE_FOR_ANNOTATION at all,
mapping T<T<KClass<...>> to T<T<Class<...>> as well.
The correct behavior is to map KClass to Class only at top level or as
an argument of Array.
There was an issue that `KotlinType.equals` called in `KotlinTypeFactory.flexibleType`
and `RawType` constructor produced endless recursion of types that wasn't
computed yet
Dmitriy Novozhilov