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.
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
- Leave only onScope callback as onLocalScope/onNonLocalScope are the same in most cases
- Pass towerGroup to callbacks as they are the same all the time
They appeared, after the changes in previous commits at
org.jetbrains.kotlin.fir.resolve.transformers.body.resolve.FirExpressionsResolveTransformer#transformDelegatedConstructorCall
The idea is that dispatch receiver is available there in old FE, but additional
diagnostic should be reported on it (see KT-38813)
This change was not made intentionaly but it was the easiest way to
support new tower data elements structure and on the other side it's the
correct behavior as for old FE.
Also, if we once would prefer the previous behavior it's still not very
hard to support it
Before this change:
- Local scopes, implicit receivers and type parameter scopes were separated.
- Static scopes for super classes were not present as a concept.
Instead of them, all-inherited-static for the current class has been used.
- During call resolution we were processing implicit receivers first and then non-local scopes,
while we should process them in the order of their syntax appearance from the closest
to the most distant
All these facts affect semantics (see test data changed here and the following commits)
The architecture changes are the following:
- FirTowerDataElement introduced as tower level that is used in resolution
(effectively it's a union type between scope and implicit receiver + isLocal flag)
- FirTowerDataContext introduced for sake of encapsulation of tower data elements' list
(it also has redundant implicitReceiverStack and localScopes)
- For each regular class we collect relevant tower data elements and add them to the current context
- Also, we preserve a special tower data context for static entities of the class
(it doesn't have class' dispatch receiver and generic parameters)
Dmitry Petrov