pyos 0037d5a7c8 JVM: erase conditional suspension markers from inline-only functions ...

Otherwise, the generated bytecode is unnecessarily suboptimal in some
(arguably weird) cases.

In the JVM backend, this was an accidental regression in #3260, as I had
not noticed that effectively inline-only functions were handled by a
separate branch in FunctionCodegen. In JVM_IR, I'm pretty sure the
redundant markers have always been there as `isSuspensionPoint` in
ExpressionCodegen never checked for effectively-inline-only-ness.

2020-04-08 12:31:23 +02:00

..

debug

JVM_IR: Lazyly generate continuation classes of suspend functions

2020-03-02 14:03:31 +01:00

destructuringInLambda

…

inlineClasses

KT-27524 Don't box (some) inline classes in suspend fun return

2020-03-27 18:29:36 +03:00

intLikeVarSpilling

…

stateMachine

…

crossinlineSuspendContinuation_1_3.kt

…

doNotReassignContinuation.kt

…

effectivelyInlineOnly.kt

JVM: erase conditional suspension markers from inline-only functions

2020-04-08 12:31:23 +02:00

nonLocalReturn.kt

JVM_IR: reuse same bodies for suspend funs and $$forInline versions

2020-04-03 19:51:45 +02:00

returnUnitInLambda.kt

…

suspendMain.kt

JVM_IR: Treat suspend main wrapper as always tail-call function

2020-02-21 12:00:54 +01:00

throwOnFailure.kt

…

varValueConflictsWithTable.kt

JVM_IR. Minor. Update bytecode text test to JVM_IR or create issues when this

2020-02-18 11:43:37 +01:00

varValueConflictsWithTableSameSort.kt

JVM_IR: default-initialize variables visible in the LVT

2020-03-02 20:17:10 +03:00