This commit support the following case.
Suppose we have such declaration:
fun <T> foo(): T { ... }
Then in code we want to use it like this: `foo() as String`.
But in LV <= 1.1 we have type inference error: "Not enough
information for type parameter `T`". This error happened because we
do not use type from cast as expected type for call.
In this commit we fix this problem and use this type as expected type
in following cases:
- our function has only one type parameter (this can be relaxed later)
- function parameter types and extension receiver type not contains `T`
Also this fix problem with `findViewById`.
Already signature was: `fun findViewById(...): View`
and was used like: `findViewById() as MyView`.
New signature is `fun <T : View> findViewById(...): T`
and old usage was broken because of problem described above
Codegen generates static backing fields for object properties.
They are initialized in class constructor but some of them are final static
and such access is prohibited in specification but it's allowed in
java bytecode <= 1.8. Such access in 1.9 bytecode cause
"IllegalAccessError: Update to static final field Object.INSTANCE
attempted from a different method (<init>) than the initializer method <clinit>"
Added additional hidden field in interface companion to pass out
companion instance from <clinit>.
#KT-15894 Fixed
Three modes:
- 'disable' (default): normalize constructor calls in coroutines only
(required because uninitialized objects can't be stored in fields),
don't insert additional code for forced class initialization;
- 'enable': normalize constructor calls,
don't insert additional code for forced class initialization;
- 'preserve-class-initialization': normalize constructor calls,
insert additional code for forced class initialization.
Stack should be spilled before inline function call and restored after
call only if one of the following conditions is met:
- inline function is a suspend function
- inline function has try-catch blocks
- inline function has loops (backward jumps)
Note that there're quite some "simple" inline functions in Kotlin stdlib
besides run/let/with/apply. For example, many string operations are
implemented as inline wrappers over Java method calls.
Singleton instance is "initialized" by delegating constructor call,
which is superclass constructor call in case of singletons (because
singletons can't have more than one constructor).
Singleton constructor is effectively split into two stages:
- before a super constructor call;
- after a super constructor call.
Before super constructor call, singleton instance can't be used directly
(see KT-20662), because neither 'this' nor static instance is
initialized yet. However, it can be used in closures, in which case a
static instance should be used (escaping uninitialized this is
prohibited by JVM). Actually using this static instance before it is
initialized (e.g., invoking a method that uses this singleton) will
cause a correct ExceptionInInitializerError.
After a super constructor call, static instance of a singleton may be
not initialized yet (in case of enum entries and interface companion
objects). However, we already have an initialized 'this', which we
should use for singleton references.
#KT-20651 Fixed
Jump out from expression (e.g., break or continue expression in call
arguments) requires stack normalization, which inserts POP instructions.
POPping an uninitialized value is similar to ASTORE, except that it
doesn't store a value to a local variable. Such POP instructions should
be removed during postprocessing of the uninitialized stores.
Synthetic accessor for 'setValue' was generated incorrectly,
specific case of KT-20491 (Incorrect synthetic accessor generated for a
generic base class function specialized with primitive type).
Make sure there's no equivalent of KT-20387 for delegated properties.
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).
Synthesized 'copy' introduces default values for parameters, which is
prohibited for regular overrides.
Report warning in language version 1.2-, error in 1.3+.
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.
This annotation is currently internal because we only commit to its
support for our own libraries. It will be used to change JVM package
names of declarations in JDK-specific stdlib additions (now called
kotlin-stdlib-jre7/8), both to preserve source compatibility of the old
Kotlin code and to solve the split package problem (KT-19258)
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")
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
Use it for char boxing/unboxing and unit materialization.
Possible to use for other purposes, for example, to add type checks
to dynamics.
See KT-18793, KT-17915, KT-19081, KT-18216, KT-12970, KT-17014,
KT-13932, KT-13930
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.
Stanislav Erokhin