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.
in 201 the order of ExternalSystemListener.EP isn't guaranteed.
But we need to update script definitions and only then we can store script models,
because they need to know script definitions additional classpath
This will speed up first script opening,
will avoid unexpected indexing because of new definitions
Script definitions are also needed for Kotlin scripting settings
Replace it with nonBlockingReadAction meaning that if update was canceled then loading will be restarted after all write events happen
Also scanning is now started after indexing
^KT-36378 Fixed
^KT-34138 Fixed
^KT-37863 Fixed
Earlier a system property was used to configure a message renderer
for the K/N compiler. The fix for KT-37550 requires getting rid of
using properties when the compiler is started in a Gradle process.
This patch allows us to specify a correct message renderer at
the K/N side depending on entry point used to run the compiler.
Issue #KT-37550
A fix for KT-37550 requires us to stop using system properties when
the compiler is started from Gradle. This patch stops reading the
konan.home property to determine a path to the compiler and requires
this path to be explicitly specified in a constructor of the
Distribution class.
Issue #KT-37550
Dmitriy Novozhilov