Mostly, these optimisations are picked from the old inference.
Also, remove exponential complexity for flexible types in approximation,
note that more correct fix for this would be to introduce new types
that corresponds just to platform types to avoid nullability problems,
but due to complexity it will be done later
#KT-31415 Fixed
- refactor script compiler to simplify extending it for repl
- add repl snippet compilation functions to the new scripting compiler
- extract util functions into appropriate files
- extract repl part into separate class
- extract bridge definition and related definitions into separate file
- remove the requirement to use Bintray repo; kotlinx-metadata-jvm is
published to Maven Central now
- remove the note about kotlin.Metadata being internal; it's public
since 1.3
Since the only use case of KmExtensionType in user code is checking if
it equals some other KmExtensionType instance, we'd like to hide as much
of its implementation details as possible, in case we want to change it
in the future
These properties have a very specific detail in their behavior, in that
the constructor's name is set to be "<init>". While this is OK for the
IR serialization, this may not always be expected in other cases, and
their rather common names (`name`, `fqNameSafe`) suggested that these
properties could be used in generic contexts.
Change all usages outside IR serialization to use
`IrDeclarationWithName.name` and nullable
`IrDeclarationWithName.fqNameWhenAvailable` instead
Although the intention of the change 9894c216c1 (#2341) was sensible, it
unfortunately caused the type mapper to map a default method incorrectly
under certain _undiscovered_ circumstances, which leads to incorrect
bytecode being generated. Specifically, this led to an exception:
java.lang.NoSuchMethodError : org.jetbrains.kotlin.idea.debugger.evaluate.KotlinDebuggerCaches$Companion.compileCodeFragmentCacheAware$default(Lorg/jetbrains/kotlin/psi/KtCodeFragment;Lcom/intellij/debugger/SourcePosition;Lkotlin/jvm/functions/Function0;ZILjava/lang/Object;)Lkotlin/Pair;
in a developer branch where this class was refactored and moved to
another module. I was not able to determine the exact reason of this
error, so I'm workarounding it by limiting this change to the IR backend
only (where it's needed), and postponing the investigation of the
failure above for now.
Mikhail Zarechenskiy