- Allow participating subtypes of functional types in conversions
- Fix several subtle inconsistencies
- Place logic about conversions at one place
Now conversions operations have two stages: before usual subtyping
check and after one. This is needed to support conversions of
subtypes (of functional types, for example). First, the compiler
checks if it possible to resolve an argument without conversion and
only then it tries to perform conversion.
Note that it'd be incorrect to perform conversion eagerly as it can
change resolve (Runnable & () -> Unit <: KRunnable), plus we can't
guess whether conversion is needed at all as it's important not to
look into supertypes if resolution doesn't actually needed it
#KT-36448 Fixed
#KT-37574 Fixed
#KT-38604 Fixed
When we generate call for 'foo', we make decision about invoking
a 'foo$default' too late, after the call arguments are generated.
If 'foo' was an override, and base class (interface) was generic,
'foo' in base class could have a different Kotlin and JVM
signature, so the arguments we generated could be generated wrong
(primitive or inline class values instead of boxes, see KT-38680).
Also, we always selected first base class in supertypes list,
which caused KT-15971.
Look into resolved call and see if we should actually call
'foo$default' instead of 'foo' when determining actual callable.
Overrides can't introduce default parameter values, and
override-equivalent inherited methods with default parameters
is an error in a child class. Thus, if we are calling a class
member function with a default parameters, there should be one
and only one overridden function that has default parameter values
and overrides nothing.
A follow-up for KT-35006:
fun f() = foo {
bar()
}
inline fun foo(crossinline x: () -> Unit) = { x() }()
inline fun bar() = TODO()
does not provide the option to navigate to bar's call site at all.
* a writing source mapper has `mapLineNumber(line, file, class)` that
inserts a new SMAP entry and returns a fake line number from it;
* a copying source mapper has `mapLineNumber(line)` that uses an
existing SMAP to resolve the line number and call the former method
on a different source mapper;
* those two types are disjoint.
Unbound it from implicit receiver stack as it only needs scope structure/declaration nestedness
Semantics for protected has been changed in a way it works in old FE
NB: We should report additional diagnostic in case of CallCompanionProtectedNonStatic.fir.kt
(see KT-38814)
In case of IrFunctionReference with type SuspendFunction (no K!) there
was a misalignment between the base class (Any) and the
origin (LAMBDA..). As a result the SuspendFunctionLowering was
getting confused and produced hanging code.
Before this commit we considered !isOverride as a sign that
function / field / accessor has no overridden symbols.
However, it's false for deserialized, because isOverride
is always false there.
This commit fixes 68 BB tests but breaks 25 BB tests (not yet muted)
Attributes are used to name continuation classes and are generated
before inline classes processing. During the processing, for override
functions in inlined classes, the compiler generates
STATIC_INLINE_CLASS_REPLACEMENT function with body of the override.
The override's body is replaced with delegating call to
STATIC_INLINE_CLASS_REPLACEMENT. However, since we need to keep the name
of the continuation class, we copy attributes from the override to
STATIC_INLINE_CLASS_REPLACEMENT. This leads to attribute clash during
AddContinuationLowering.
So, to fix the issue, do not use the attribute of
STATIC_INLINE_CLASS_REPLACEMENT in original->suspend map.
As an optimization, do not generate continuation for the override
function.
Instead of generating these annotation classes as package-private on
JVM, serialize their metadata to the .kotlin_module file, and load it
when compiling dependent multiplatform modules.
The problem with generating them as package-private was that
kotlin-stdlib for JVM would end up declaring symbols from other
platforms, which would include some annotations from package
kotlin.native. But using that package is discouraged by some tools
because it has a Java keyword in its name. In particular, jlink refused
to work with such artifact altogether (KT-21266).
#KT-38652 Fixed
Pavel Punegov