MockLibraryUtil runs the compiler in the new class loader, which is
useful for IDE tests to avoid loading KotlinCoreEnvironment, but is not
needed and is suboptimal for compiler tests.
Also use another method in AbstractForeignAnnotationsTest to assert that
there are no files in the compiled libraries
When a local function or class A creates an instance of a local class B
capturing an outer variable 'x', it should use ref for 'x', but not the
value of 'x'.
When a local function is captured, corresponding field accesses are
later transformed by the inliner. It doesn't have enough information to
restore the original semantics completely, so it has to rely on field
names. Local functions can be overloaded or can have names matching
local variable names, in both cases we generated fields with the same
name for captured values.
Now, we use the same '$<local-class-number>' suffix for field names for
local functions as it is present in the corresponding local class name.
This allows to distinguish captured local functions from captured local
variables and between different overloads of a function with the same
name.
#KT-19827 Fixed
#KT-18639 Fixed
Given a singleton class 'S' with possibly uninitialized static instance
(enum entry, interface companion object).
Such singleton can be referenced by name, or as an explicit or implicit
'this'.
For a given singleton class 'S' we
either use 'this@S' from context (local or captured),
or 'S' as a static instance.
Local or captured 'this@S' should be used if:
- we are in the constructor for 'S',
and corresponding instance is initialized
by super or delegating constructor call;
- we are in any other member of 'S' or any of its inner classes.
Otherwise, a static instance should be used.
It's necessary for performance, because there are some resolution
parts that actually can be omitted and at the same time they aren't
very cheap (like inference or value arguments types checking)
On JVM, strip @EnhancedNullability annotation from inferred types for
functions, properties, and local variables, so that these annotations
do not "escape" from Kotlin declarations.
If an expression with type annotated with @EnhancedNullability is used
as a function expression body, or property initializer, or variable
initializer, and corresponding type can not contain null,
generate nullability assertions for this expression.
Dmitry Petrov