- 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.
As soon as JVM IR is enabled by default (in language version 1.5), use
the CLI argument `-Xuse-old-backend` or Gradle option `useOldBackend` to
switch to the old JVM backend.
Module 'oracle.desktop' is not guaranteed to be present in JDK. Also,
its usage in these tests doesn't check anything new that isn't already
checked by usages of jdk.net and jdk.httpserver.
This gives us more precise type information and can enable backend
optimizations. This was motivated by when expressions not compiled
to table switches in the JVM_IR backend.
Fixed KT-36845.
Reveals discrepancy in LVT presence on lambda implementations on the
old and new backend.
The generated code in the constructors of Suspend Lambda objects is
identical, but the IR backend generates an LVT with the constructor
parameters.
The user has to be very insistent to see this ("for step into" +
disabling "Show only kotlin variables"), but it is an observable
difference.
This flag was added a long time ago, at the time when we weren't sure if
we were going to keep the naming of local and anonymous classes
completely equal to the naming in the old backend. Now that we've
decided that we won't keep it equal and there are a lot of differences
already, it's not useful anymore.
- Use typed Wasm tables for each interface method to avoid runtime
function type check
- Use linear search by implemented interface rather than by individual
virtual function signature
Mads Ager