Divide incompatibility on two groups: strong and weak. Strong incompatibility means that if declaration with such incompatibility has no `actual` modifier then it's considered as usual overload and we'll not report any error on it.
#KT-20540 Fixed
#KT-20680 Fixed
* add `then` with only one parameter to make usages from Kotlin more idiomatic
* add overload static `resolve` which accepts Promise<S> according to the spec
* add helper functions for `then` to simplify chained usages
when Promise is returned from `then` or `catch` (workaround for KT-19672)
build.xml was also changed to incorporate contracts in
mock-runtime-for-tests.jar, because it is using Standard.kt, which, in
turn, has contract-annotated functions.
==========
Introduction of EffectSystem: 17/18
- Make AbstractDiagnosticsTest dump function contracts
- Add diagnostics tests on parsing contracts
- Add diagnostics tests on smartcats in presence of functions with
contracts
- Add diagnostics tests on initialization and flow in presence of
in-place called lambdas
==========
Introduction of EffectSystem: 16/18
- Add method "doTestWithStdLib" which launches test with stdlib
- Change GenerateTests.kt to generate cfg tests with stdlib from
folders 'cfgWithStdLib' and 'cfgVariablesWithStdLib'
==========
Introduction of Effect System: 14/18
- Add ContractDescriptorRenderer
- Add option to dump function contracts in DescriptorRendererOptions
- Add parsing of LANGUAGE_VERSION directive in AbstractLoadJava
- Add tests on serialization-deserializaton identity of contracts
==========
Introduction of EffectSystem: 13/18
Required as a workaround for Proguard bug
https://sourceforge.net/p/proguard/bugs/664/
When processing bytecode generated by Kotlin compiler for constructor
call with stack spilling during arguments evaluation, ProGuard performs
an equivalent transformation for the bytecode, but emits invalid stack
frame information.
In JVM 1.6, such invalid stack frames are ignored and re-evaluated by
JVM during bytecode verification.
In JVM 1.8, such invalid stack frames cause VerifyError.
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
This is needed to avoid the split package problem on Java 9 (KT-19258):
both kotlin-stdlib.jar and kotlin-reflect.jar export the package
kotlin.reflect
Mikhail Zarechenskiy