This commit fixes the following tests:
- KotlinSteppingTestGenerated.Custom.testStepOutInlineFunctionStdlib
- KotlinSteppingTestGenerated.StepOut.testStepOutSeveralInlineArgumentDeepest
If a part of an 'if' condition is an inline function call, we need to insert the original condition line after it. Otherwise, the debugger will think it is inside the inline function implementation. Obviously, this breaks stepping – instead of the 'if' body, we go on stepping through the inline function.
This commit fixes 'KotlinSteppingTestGenerated.StepOver#testSoInlineLibFun' test.
This commit fixes the following tests:
- KotlinSteppingTestGenerated.StepOver#testSoInlineLibFun
- KotlinSteppingTestGenerated.StepOver#testSoInlineIterableFun
- KotlinSteppingTestGenerated.StepOver#testSoInlineFunOnOneLineFor
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.
Previously, resolved call is expected to have SAM converted argument map
if SamConversionPerArgument is enabled. However, if SAM argument is
followed by vararg parameter and an array _without_ a spread operator is
passed, New Inference left a type mismatch error on a resolved call, which
made that resolved candidate filtered out. Instead, another resolution
result wihtout SAM converted arugment map will be provided.
All other logics, such as adding SAM conversion type op and lowering SAM
conversion and/or call references, are already there for resolved calls
without SAM converted argument map. This change just relaxes the bailout
condition so that array passed to vararg after SAM argument can be
handled in JVM IR.
- Uncomment tests
- Add proper visibility to companion field
+ Make exception for interfaces -> they need to respect language versions 1.8
before they can put private members there.
- Adjust synthetic accessor lowering to look for enclosing classes with access
via companion object.
New resolution applicability is needed in cases when error is found,
but candidate still should be selected. Currently there are two cases,
when this behaviour is required:
- unstable smartcast (choose candidate with non-nullable parameter)
- unknown lambda parameter type (against non-functional expected type)
KT-36264
Yan Zhulanow