The enumEntriesIntrinsicMultipleEnums.kt test was supposed to check that
JVM backend generates 3 `$EntriesIntrinsicMappings` classes: for X, for
Y, and for Z. Mappings classes are generated for enums without
`entries`, i.e. Kotlin enums compiled without `EnumEntries` language
feature, and Java enums. The test incorrectly _enabled_ the language
feature for X though, and `$EntriesIntrinsicMappings` for X was
generated anyway because of KT-61208.
To keep the original intention of the test, I'm disabling the language
feature for X, so that it will be considered as enum without `entries`.
KT-61208 will be fixed in a separate commit (with separate tests).
The boxInline and bytecodeText tests changed their meaning when language
feature EnumEntries started to be enabled by default, so those changes
are a continuation to ebd43fc8c0. The behavior did not change after
enabling the feature, once again because of KT-61208.
Also, remove obsolete error suppressions which are no longer needed
after 64c8ce18a0.
Most of these tests check the specific structure of lambdas when they
are generated as classes, and they start to fail once invokedynamic
lambdas are enabled by default.
Ensure that when .entries is accessed from an inline function body
or lambda argument, EntriesMapping are properly generated and used
without excessive mappings and duplicated fields
#KT-53236
E.g. in `x + f()` where `f` is an inline lambda, the instructions for
`+` should have the line number of that expression (while previously
they instead had the line number of the last line of the lambda).
^KT-51738 Fixed
We are going to deprecate `WITH_RUNTIME` directive. The main reason
behind this change is that `WITH_STDLIB` directive better describes
its meaning, specifically it will add kotlin stdlib to test's classpath.
1. Enum entry fields don't have nullability annotations.
2. Enum class special methods (values, valueOf) are not 'final'
(although they probably should be, javac generates corresponding
methods without ACC_FINAL flag).
3. Enum class special methods don't have nullability annotations.
4. Don't generate synthetic accessor for enum entry class constructor.
KT-37019 KT-37020 KT-37021
This commit fixes the following tests:
- KotlinSteppingTestGenerated.StepOver#testSoInlineLibFun
- KotlinSteppingTestGenerated.StepOver#testSoInlineIterableFun
- KotlinSteppingTestGenerated.StepOver#testSoInlineFunOnOneLineFor
This method was introduced in c204e8fc67 "just in case" and was never
used. Therefore we're free to change its semantics and use it in all new
generated code (with API version >= 1.4), without even worrying that the
newly used API will leak from inline functions in stdlib when used with
an older API version. Since we agreed to change the type of thrown
exceptions to java.lang.NPE in KT-22275, invoke a new method
throwJavaNpe now which throws that exception instead of KNPE.
Note that the additional method that takes an exception message is still
unused and exists just in case we need to use it in the future. The new
method throwJavaNpe is public also "just in case" we need to invoke it
in the future; currently it's not invoked from the bytecode.
#KT-22275 In Progress
Dex ignores subsequent line numbers for same instructions and interprets
instruction after inline as if they were inlined. This makes debugger
behaves as if there's nowhere to stop on line with breakpoint.
This also makes stepping through inline function consistent with
non-inline analog. In both context debugger now stops on '}'.
#KT-18949 Fixed
#KT-17120 Fixed
- Turn some const conditions into non-const conditions
- Make sure inlined const values are used where required
(otherwise they are eliminated by POP backward propagation)
Finnaly markers are used only for non-local return processing and are removed after inlining to non-inline functions, same deletion should be performed on inlining to anonymous objects
#KT-16532 Fixed
Remove redundant NOPs during bytecode optimization.
NOP instruction is required iff one of the following is true:
(a) it is a first bytecode instruction in a try-catch block (JVM BE assumption);
(b) it is a sole bytecode instruction in a source code line (breakpoints on that line will not work).
All other NOP instructions can be removed.
Note that it doesn't really affect the performance for mature JVM implementations.
However, the perceived quality of the generated code is somewhat improved :).
Related: KT-15609
Nikita Nazarov