Take local/anonymous classes and their inner classes into account.
Simplify approximation: use first available super classifier instead
of first super class. This approximation should only happen for
private declarations that were not previously approximated by frontend.
So basically the only requirement for the approximated types is to be
denotable. Note that this only works if the types are not used later.
JVM uses a different string table implementatin as it needs exact
types of private members for reflection.
^KT-20996 Fixed
Before this commit, during the resolve of companion objects we used
the same context than for any nested class. However, during companion
object resolve we should not have companion object receiver itself
accessible in any case (in particular, it should not be accessible
in constructor). So in this commit we introduced separate context
for this purpose.
- KtClassLikeSymbol.primaryConstructor was removed
- Constructors were removed from getCallableMembers because
constructors has no name (or special name `<init>`) and previous
implementation was incorrect
- KtScope.getAllSymbols returns constructors as before. Before it was
like this because of the incorrect implementation of getCallableMembers
- getConstructors has sence only for class scope,
for the rest cases it is empty
This feature is supported only on JS backend so those tests on JVM
are meaningless. Also those tests had passed on jvm because of
old codegen tests didn't use `MODULE` directive and analyze all
files in tests in single module
In old tests coroutine helpers was added as separate module named `support`
instead of additional files for current module.
So to safe compatibility with old testdata we need to filter this dependency
This is needed to keep compatibility with old format, when all those
helpers were generated dynamically on test run in one file, so
you can reference helpers methods from java code just importing
`helpers.CoroutineUtilKt`
This change improves the debugging experience around local functions
on the IR backend. The changes include moving old
checkLocalVariablesTable (cLVT) tests to the new stepping/local variable
infrastructure in order to refine the tests and further define the
behavior of the two JVM backends, and their differences.
The primary ported test case is cLVT/localFun.kt that documents the
discrepancy in implementation strategy for local functions on the two
backends. The old backend implements local functions as lambdas
assigned to a local variable while the IR backend lifts them out as
static funtions on the surrounding class. The discrepancies and their
consequences are documented in bytecodeListing, idea-stepping,
localVariableTable and debugStepping tests.
The only _code change_ is disabling the captured variable name
mangling for captured variables on the IR backend. Captured variables
are passed as arguments to the static function, so in the debugger,
they really just are local variables. For them to show properly in the
debugger and be detectable by evaluate expression, they simply need no
mangling.
Finally, this change cleans 3 redundant cLVT tests, copyFunction.kt
and destructuringInlineLambda.kt and destructuringInFor.kt, that are
all covered in the new suite. The stepping behavior needs to be made
precise around for loops, but that is an entirely seperate issue.
It's not correct to expect that the backend generates the `when` in this
test as tableswitch because there are only two branches. JVM IR has a
cutoff in the when optimization and generates `when`s with fewer than 3
branches as if-else chains, which is probably better. Note that there's
also a corresponding box test in when/enumOptimization/, so the backend
behavior is still tested.
Mikhael Bogdanov