KClass can be 'unboxed' to a plain Java class. Debugger should be aware of this.
Unfortunately, this commit is not enough to fully support this scenario, as it's impossible to invoke KClass methods/extension on java.lang.Class instance. There should be an additional diagnostic that will forbid such calls.
This commit fixes the following tests:
- KotlinSteppingTestGenerated.Custom.testStepOutInlineFunctionStdlib
- KotlinSteppingTestGenerated.StepOut.testStepOutSeveralInlineArgumentDeepest
The main goal is to make behavior similar to what happens in Java. For instance, now we always skip lambdas.
Also, we can reliably use '$i$f' and '$i$a' synthetic local variables. There is no need in complicated hacks any more.
This reverts commit ce21a559
Because of the erroneous behavior in 'BuilderFactoryForDuplicateSignatureDiagnostics.groupMembersDescriptorsBySignature', two functions with arguments of different inline class types are considered to have the same JVM signature.
Before the error wasn't reported, as classes didn't have proper source elements.
This issue has to be fixed before enabling ranking tests.
Before this commit, the substituted FunctionDescriptor didn't have a source element.
As a result, 'CodeFragmentParameterAnalyzer.isCodeFragmentDeclaration' failed to recognize such a descriptor as fragment-local, and it was erroneously captured.
It seems like it doesn't make much sense to create expression code fragments.
People type statements or several expressions separated with a semicolon to a single-line expression line.
That is exactly what block code fragment was designed for.
Yan Zhulanow