We don't want to deprecate freezing at all, but it is possible
that freezing, new memory model and lazy global initialization
combination might not work in some cases. It might be a problem
when such case appears in 3rd-party library that user can't fix.
To mitigate this problem this commit introduces `freezing` binary
option. It has three variants:
* Full - ol' good behavior.
* Disabled - well, no freezing at all.
* ExplicitOnly - a compromise when user want to freeze something
themselves, but something is messed up during globals initialization.
Before 1.6 we wrote suspend functional types with last parameter of
kotlin.coroutines.experimental.Continuation type to .kotlin_metadata
files. For example, kotlin-stdlib-common. Thus, we need to read
them, since coroutines have been released in 1.3 and we need to be able
to read stable binaries.
This fixes a performance problem in the case where the lock object
is a capture and the monitor enter/exit happens directly on
field loads. When the locking happens on field loads instead of a
local, the JVM cannot prove that locking is balanced. That has
the consequence that the code is runs very slow (always in the
interpreter).
^KT-48367 Fixed.
Also, add `classId` default value to the `FirErrorResolvedQualifierImpl`
just as in `FirResolvedQualifierImpl` - it seemed inconsistent that
we can have a class symbol in error-resolved qualifier, but the
`classId` field will be `null`
Because those test are single Java files, many of them use a top-level
class as a container for multiple classes to be tested. Such tests do
almost nothing if those nested classes aren't handled.
Calling initRuntime requires some machinery from the
objc module (e.g. adding the toKotlin method to NSObject).
Include this module to the tests to allow full runtime
initialization in the tests
This is already the case for straightline code such as
```
inline fun <R> f(size: Int, block: () -> R): R {
var result: R
result = block()
return result
}
```
However, if the local variable introduction happens at a merge
point as in the following example, we allow the unboxing but
only do it halfway. The initialization of the local is still
done with a null value.
```
inline fun <R> f(size: Int, block: () -> R): R {
var result: R
while (true) {
result = block()
if (size == 0) break
}
return result
}
```
This change disallows unboxing for this move complicated
case as well by bailing out if a local use is with a
TaintedBoxedValue (merge of Object and Integer).
^KT-48394 Fixed.
Sergey Bogolepov