Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[kotlin][debugger] Add support for removed line numbers from lambdas with parameter destructuring #2834

Open
wants to merge 6 commits into
base: kt-master
Choose a base branch
from

Conversation

nikita-nazarov
Copy link
Contributor

This pull request adds debugger support for new debug info format for lambdas with parameter destructuring. In the new format line numbers will not be added for the part where destructuring happens.

Corresponding issue: https://youtrack.jetbrains.com/issue/IDEA-335314/Debugger-destructured-parameters-are-not-visible-when-stepping-into-a-lambda

Compiler side pr: https://kotlin.jetbrains.space/p/kotlin/reviews/1150/timeline

…n the Kotlin debugger

Previously there was no capability to set different expectations for evaluate expression results when compiling with K1 and K2. At the same time, we can differentiate test outputs with '.out' and '.k2.out' suffixes. So it makes sense to add the same differentiation capability for evaluation.
…er destructuring

This commit only works in pair with the corresponding change in the Kotlin compiler, that erases line numbers set on parameter destructuring opcodes in lambdas. The only difference on the debugger side is the removal of a condition that filters inline function borders with the same source file name. To explain why this is needed let's take a look at a sample bytecode of a lambda with parameter destructuring:
```
private static final kotlin.Unit main$lambda$0(A);
  // Fake line number with source 'fake.kt' can be inserted here
  // $i$a$... starts here
  // START OF DESTRUCTURING
  ...
  // END OF DESTRUCURING
  // First line number in the method goes here
  ...
```
Let's suppose it was inlined like this:
```
inline fun foo(...)

foo { (x, y) -> ... }
```
The `$i$a$foo` variable that captures borders of the inlined lambda will start right before the parameters are destructured, however since there is no dedicated line number at the start of lambda, the source file of the start of the border will be 'fake.kt'. This situation was not possible before so the condition that was removed really didn't do anything.
…turing

This commit only works in pair with the corresponding change in the Kotlin compiler, that erases line numbers set on parameter destructuring opcodes in lambdas. It introduces a heuristic that corrects stepping into lambdas with parameter destructuring.
@nikita-nazarov
Copy link
Contributor Author

@zuevmaxim

@@ -3,7 +3,7 @@ Run Java
Connected to the target VM
stepIntoStdlibFacadeClass.kt:6
_Arrays.!EXT!
Intrinsics.!EXT!
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, I couldn't understand what has actually changed in this test. I couldn't reproduce the original output in Intellij.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like it is affected by this code:

            if (location != null && location.isMethodEntryLocationWithoutLineNumber()) {
                currentSteppingSize = StepRequest.STEP_MIN
                return StepRequest.STEP_OVER
            }

You were not able to reproduce the error, because val DISABLE_KOTLIN_INTERNAL_CLASSES by debuggerPreferenceKey(false) is disabled by default in tests

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyway, isMethodEntryLocationWithoutLineNumber seems not enough to limit the fix to parameter destruction only. However, this does not look bad unless this flag is disabled, as only generated code should be located before the first line

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants