last-exclusive progressions (i.e., "until" progressions and loop over
array indices).
This change makes it possible to correctly implement the handling of
"step" progressions. Computing the last element of a stepped progression
requires that the last is inclusive.
Also invert the while loop (into if + do-while) that is used when
lowering for-loops over progressions that cannot overflow. This keeps
the performance characteristics closer to the ForLoopsLowering in
kotlin-native, since the goal is to converge to this shared version.
Also used IrType instead of KotlinType, where possible.
https://github.com/JetBrains/kotlin/pull/2390https://github.com/JetBrains/kotlin/pull/2305
Unfortunately this cannot currently be done for the extension overload which accepts a radix due to behavior difference with regard to invalid radix values.
Remove "JVM_TARGET: 1.6" directive from box tests and remove tests with
JVM target 1.8. By default, box tests are run with JVM target 1.6, and
there's an additional configuration `codegenTarget8Jvm8Test` that runs
all box tests with JVM target 1.8.
Also, remove box tests with JVM target 1.6. They aren't needed because
even if we manage to generate incorrect bytecode with target 1.6, the
corresponding box tests will catch that
This fixes Java interop of inline functions, which use coroutines.
However, we cannot transform the state-machine. Thus, we generate
a $$forInline counterpart for suspend functions (similar to inline
suspend functions) and invokeSuspend$$forInline for lambdas if these
coroutines are going to transformed (i.e. are declared inside inline
functions).
During transformation we just skip method with state-machine and
transform the $$forInline counterpart. Of course, if inline site is
inline itself, we generate both state-machine version (which will be
dropped during the next transformation) and $$forInline version.
Consequently, the final version of the coroutines will not have
$$forInline counterpart.
Unfortunately, since CompileKotlinAgainstInlineKotlin tests do not allow
java sources, the tests for the interop are usual box tests.
#KT-30707 Fixed
We get the info for the underlying progression and invert it. For
progressions whose last bound was open (e.g., `until` loop), the
reversed version will have an open first bound and so the induction
variable must be incremented first.
Also unified the way of extracting HeaderInfo out of changed calls
(e.g., `indices.reversed()`), and fixed declaration parents in
ForLoopsLowering.
HeaderInfo object, and modifying the operator in the loop condition.
The "additional emptiness condition" is no longer necessary with this.
The open/closed property was removed from HeaderInfo in an earlier
commit, but bringing it back in to simplify the loop building makes
more sense.
Also expanded tests for evaluation order of range bounds.
do-while with enclosing "not empty" check).
Also do not add additional "not empty" condition for `until` loops when
the given bound is a constant != MIN_VALUE.
non-specialized progressions, including "step" progressions.
DefaultProgressionHandler uses the "first/last/step" properties of
the progression when building the loop header.
Also deleted StepHandler. Since the HeaderInfo.needLastCalculation is
only set to true for handling step progressions, deleted that property
and all associated logic around it.
* In blocks, discard the result of any statement that has a return
type other than void. This was previously done by wrapping each
statement into an "implicit Unit conversion" that was actually
compiled down to a stack pop instead. If an expression happened to
already have type Unit, however, such a conversion was not inserted,
resulting in a stray reference on the stack. These conversions are
now redundant and should probably be removed.
* In assignments and non-exhaustive conditionals, materialize a Unit
on the stack to avoid depth mismatches that trip up the bytecode
validator. Because such expressions are generally used at block level
(and, indeed, the frontend will reject a non-exhaustive conditional
used as an expression), combined with the above change this results
in no additional GETSTATIC opcodes, as they are immediately removed
by the peephole optimizer.
