Use the same approach that is used for creating function type classes
(Function{0,1,...}) + add Cloneable to supertypes of Array and primitive arrays
#KT-5537 Fixed
The problem with BasicInterpreter is the following:
it creates BasicValue objects that should be replaced in favor of StrictBasicicValue
See commit message in 25c6ac1 for clarification
#KT-14447 Fixed
Mostly this commit replaces instances of original BasicValue from ASM
with ones of StrictBasicValue having strict equals implementation
Optimization issue was related to non-symmetric 'equals':
- NotNullBasicValue("java/lang/Object").equals(BasicValue("java/lang/Object")) == false
- BasicValue("java/lang/Object").equals(NotNullBasicValue("java/lang/Object")) == true
#KT-14242 Fixed
There are mainly two kind of changes:
- skipping 'componentX' calls for destructuring entries named _
- fixing local variable table for them
- skip entries for destructuring entries named _
- use $noName_<i> format for lambda parameters named _
#KT-3824 Fixed
#KT-2783 Fixed
The main change here is addition of a check that NotNullBasicValue instances
are not being created for non-reference types
Exactly this change should be used instead of f25f0db10e
The latter commit lead to problem described in the KT-14242 issue:
v.getType().getSort() == w.getType().getSort() && (v.getType().getSort() != Type.OBJECT || v.equals(w))
Problem is that the condition above returns true without calling `v.equals(w)`,
because the sort of type is ARRAY, not OBJECT, so testArray was being treated
as NotNullable erroneously
So the second part of this change is effectively revering mentioned commit
#KT-14242 Fixed
To simplify migration from 1.0 to 1.1, do not allow data classes to
automatically implement abstract equals/hashCode/toString declared in
super-interfaces (KT-11306) if "-language-version 1.0" is specified
Private-in-file declarations conflict with public overload-equivalent declarations
in other files in the same package.
Move functions for grouping possible redeclarations to OverloadResolver
(since they are used only there).
Refactor redeclarations / conflicting overloads reporting.
Change getAllOverriddenDescriptors contracti, now it returns
original (not substituted) descriptors without any duplicates.
First of all it's necessary in CodegenUtil.getDelegates to avoid
duplicates (see assertion there), but also it's convenient for all
other usages of this method
#KT-8154 Fixed
23 invokes in KFunctionFromReferenceImpl (and consequently, in FunctionImpl)
were needed before 1576160390: a wrapped function
reference must have had the necessary invoke to be called as an instance of a
specific function type. After 1576160390, this is
not needed anymore because KFunctionFromReferenceImpl is now an internal
implementation detail of reflection, and no invoke is ever called on it.
The only place where their get/set methods were used was in
KPropertyNImpl.Getter.invoke, and it's fine if that results in a reflective
call instead (KPropertyN#getter is not available without kotlin-reflect.jar
anyway). The test data has been changed because a package local Java field is
not accessible via reflection
Generation of callable reference's signature in codegen should use the same
mechanism for obtaining the signature as the runtime in RuntimeTypeMapper,
namely DescriptorUtils.unwrapFakeOverride(...).original
#KT-13700 Fixed
Replace coercion from VOID with call 'pushDefaultValueOnStack'
It's necessary because coercion of VOID to java/lang/Object ends with Unit instance on stack
that makes variables spilling algorithm thinking that variable is Unit
#KT-13409 Fixed
Before this change everything works just fine for 'handleResult' methods
accepting non-Unit parameters
For other cases the same coercion-to-unit strategy is in plain lambdas:
- if last statement is not Unit type, execute it, pop from the stack, then put Unit instance
- for 'return@label' (no expression) just put Unit on the stack
#KT-13531 Fixed
Both primitive int and wrapper type java.lang.Integer are represented by the
single type kotlin.Int in Kotlin, so inequality between the corresponding
KClasses was confusing here. To keep the old behavior, one may call 'k1.java ==
k2.java' instead of `k1 == k2`
#KT-13462 Fixed
It fixes VerifyError with coroutines on Dalvik happening because of
variables spilling before/after suspension point
BasicInterpreter from ASM does not distinct 'int' types from other
int-like types like 'byte' or 'boolean', neither do HotSpot and JVM spec.
But it seems like Dalvik does not follow it, and spilling
boolean value into an 'int' field fails with VerifyError on Android 4,
so it's necessary to distinct int types for variables spilling
#KT-13289 Fixed
Alexander Udalov