- See the documentation for `DeserializedMemberScopeHelper` for the full
info about the fix and the issue
- Add `preserveDeclarationsOrdering` setting to
`DeserializationConfiguration`
- Enable this setting in `DeserializerForClassfileDecompiler`
- Also, use `List` instead of `Collection` to pass members to
`DeserializedMemberScope`. It is done to emphasize that the order of
the members is important and may be used
- Review: https://jetbrains.team/p/kt/review/1627
- ^KT-41346 Fixed
Reimplement the same hacky approach used in the old backend (see
cc2fe6b0c6).
Previously, the debugger incorrectly stepped into Collections.kt on
"step over" inline function calls from stdlib like 'any'.
Since `if` and `when` expressions are represented the same way in IR,
the behavior is fixed for both of them. It's not the case in the old JVM
backend, where stepping over `when` conditions still suffers from the
same problem, which the newly added test checks.
Before this change, a test with incorrect .ir.out could pass if the test
execution result was equivalent to the main .out file, which was a bit
confusing.
Loads of temporary variables that contain constants are replaced
with a copy of the constant. This avoids locals loads and stores.
However, the copy of the constant needs to have the offset of
the load and not of the original constant.
Fixes KT-41963.
This fixes smart step into for delegated member functions.
Additionally, we align on the string "memberFunctionName(...)"
for expression non-null checks for both JVM_IR and JVM
backends.
Do not suggest to remove type for public declarations
#KT-38915 Fixed
Do not show intention to specify type when corresponding quickfix is available
#KT-39026 Fixed
Bytecode generated by JVM IR ensures that on multiline expressions,
every call is stepped over, which seems better than in the old backend.
Also remove kt34905.kt since it duplicates this test case.
The only difference seems to be that step into IImpl.fooOverride is
actually supported in JVM_IR. Also fix slightly incorrect line numbers
in the comments.
The difference is that JVM_IR generates line numbers for the
constructor field initialization.
In this case:
```
29: class B {
30: // comment
31: val bPropVal: Int,
32: // comment
33: var bProbVar: Int
34: ) {
```
the line numbers for the field initializations are 31 and 33 where
in the current backend the whole constructor has line number 29.
Ilya Kirillov