Previously it was linear scan, failing on unbalanced suspension markers.
Now, I use CFG to find end markers, which are reachable from start
markers. Using CFG allows to walk through suspension point instructions
only, since they form region.
If, for some reason, end marker does not exist (inliner or unreachable
code elimination pass remove unreachable code) or is unreachable,
just ignore the whole suspension point, as before.
#KT-33172 Fixed
#KT-28507 Fixed
- Don't produce mapping for closing bracket in case of expressionBody
- Map Kt*Function declaration into corresponding js fun declaration
- Update test data & add new test
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.
re-ordering the lowering phases.
The changes in InterfaceLowering are necessary so that IrElements that
target the removed functions are re-targeted to the new functions in
DefaultImpls. This affects local functions in interface functions since
now LocalDeclarationsLowering comes before InterfaceLowering.
The synthesized arguments caused the size of default value mask off by
one when it is close to the boundary of Int.SIZE, which in turn
resulted in wrong signature at call sites.
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
Ilmir Usmanov