When generating collection element receiver (such as 'a[i]'), accessible
descriptor for get/set operator should be used.
Otherwise, if the corresponding get/set operator fun is called via an
accessor, its argument types may be different in case of generic fun
specialized with primitive types.
#KT-20387 Fixed
Accessor parameter types may be different from callee parameter types
in case of generic methods specialized by primitive types:
open class Base<T> {
protected fun foo(x: T) {}
}
// in different package
class Derived : Base<Long> {
inner class Inner {
fun bar() { foo(42L) }
}
}
Synthetic accessor for 'Base.foo' in 'Derived' has signature '(J)V'
(not '(Ljava.lang.Object;)V' or '(Ljava.lang.Long;)V'),
and should box its parameter.
Note that in Java the corresponding synthetic accessor has signature
'(Ljava.lang.Long;)V' with auto-boxing at call site.
#KT-20491 Fixed
See
https://youtrack.jetbrains.com/issue/KT-19251https://github.com/puniverse/quasar/issues/280https://bugs.openjdk.java.net/browse/JDK-8046233
Inline function calls (as well as try/catch expressions) in constructor
arguments produce bytecode that spills stack, and stores uninitialized
objects (created by 'NEW C', but not initialized by 'C.<init>') to
local variables. Such bytecode is valid according to the JVM spec, but
confuses Quasar (and other bytecode postprocessing tools),
and fails to verify under some (buggy) versions of JDK 8.
In order to avoid that, we apply 'processUnitializedStores' already
implemented for coroutines. It moves 'NEW' instructions after the
constructor arguments evaluation, producing code like
<initialize class C using Class.forName>
<evaluate constructor arguments>
<store constructor arguments to variables>
NEW C
DUP
<load constructor arguments from variables>
INVOKESPECIAL C.<init>(...)
NB some other expressions, such as break/continue in the constructor
arguments, also can produce "weird" bytecode: object is created by a
'NEW C' instruction, but later (conditionally) POPped from stack and
left uninitialized. This, as we know, also can screw bytecode
postprocessing. However, it looks like we can get away with it ATM.
Otherwise it looks like we'd have to analyze constructor arguments, see
if the evaluation can "jump out", and perform argument linearization in
codegen.
Similar to enum entry initialization, when we have a companion object
in an interface, its constructor (or clinit) initializes its state
before the instance field in corresponding interface is initialized.
So, interface companion object must be accessed via a captured object
reference (#0, or #0.this$0 for inner anonymous objects).
The main changes are in jvm_package_table.proto and ModuleMapping.kt.
With JvmPackageName, package parts can now have a JVM package name that
differs from their Kotlin name. So, in addition to the old package parts
which were stored as short names + short name of multifile facade (we
can't change this because of compatibility with old compilers), we now
store separately those package parts, which have a different JVM package
name. The format is optimized to avoid storing any package name more
than once as a string.
Another notable change is in KotlinCliJavaFileManagerImpl, where we now
load .kotlin_module files when determining whether or not a package
exists. Before this change, no PsiPackage (and thus, no JavaPackage and
eventually, no LazyJavaPackageFragment) was created unless there was at
least one file in the corresponding directory. Now we also create
packages if they are "mapped" to other JVM packages, i.e. if all package
parts in them have been annotated with JvmPackageName.
Most of the other changes are refactorings to allow internal names of
package parts/multifile classes where previously there were only short
names.
Before this change, we were computing the visibility of an inherited
private property setter, and ISE at AsmUtil.getVisibilityAccessFlag
happened ("invisible_fake is not a valid visibility in backend")
Search abstract members in unsubstituted scope to avoid computation
of substituted descriptors for each type (effectively for each SAM call)
#KT-20055 In progress
It might be helpful for performance as these methods are called
for each resolution candidate and in the same time they scan
the whole overridden tree of a callable member
Enum entries are "special" kind of singletons that should be
referenced as a captured 'this' instance inside during entry
initialization, because corresponding static fields in enum class
are not initialized yet.
#KT-7257 Fixed
In an inner class of the enum entry class, enum entry reference should
be generated as an outer 'this', not as a enum entry access, because
enum entry itself may be not initialized yet.
In Kotlin 1.1 and before, there were no nullability assertions on
extension receivers, because receiver is resolved with NO_EXPECTED_TYPE.
So, if an expression of platform type is passed as an extension receiver
to a non-private function, it would fail with IllegalArgumentException.
However, if the function is private, then we generated no parameter
assertions under assumption that such function can be called from Kotlin
only, and all arguments are checked on the call site. Thus 'null' could
propagate indefinitely.
In Kotlin 1.2, we do the following:
- Generate nullability assertions for expression receivers.
NB nullability assertions are stored for ReceiverValue instances, not
for expressions: given expression can act as receiver in different
calls, each with an expected receiver type of its own.
- Generate nullability assertions for extension receivers of private
operator functions.
NB it still can throw NPE for some particular "optimized" cases, but at
least those nulls would not propagate indefinitely.
This behavior is disabled by an "advanced" command-line option
'-Xno-receiver-assertions'.
Generate synthetic accessors for property accessors only if the
corresponding methods are accessible in the current context.
#KT-19306 Fixed Target versions 1.1.5
In the case the single parameter of override has `Integer` type instead
of `int` type (while in common case it would be just `int`)
See the comment inside forceSingleValueParameterBoxing for clarification
#KT-19892 Fixed
Lateinit local vars are guaranteed to be non-null after store.
So we mark such stores as storing non-null value
(could be useful for some other constructs, too),
and optimize null checks accordingly.
Dmitry Petrov