1. Use 'x' for each parameter, which is not an inline class, every
possible clash is handled by signature rather than name. This change
makes more API changes binary-compatible. So, the changes are in line
with the vision of inline classes are value classes, like primitives.
2. Take return type into account when mangling a function if the return
type is inline class. Otherwise, boxing bridge will not be generated,
which leads to CCE at runtime.
Discarding the value used to leave an unused-but-never-destroyed
temporary variable. It's best to not separate calls to `enterTemp`
and `leaveTemp`.
Not sure what kind of test to add though, since this is minor -- if the
result of the comparison is discarded, then the entire statement is more
or less pointless.
#KT-42251 Fixed
Unlike signed integers, a larger unsigned type does not mean a lower
minimum value, so `x - 1` can overflow even if `x` is casted to a larger
type.
#KT-42186 Fixed
`C?` can be unboxed into `T?` if if wraps a reference type `T!!`, but in
this case `null` is not a valid value to pass to `toString-impl`.
#KT-42005 Fixed
The JVM BE inlines calls to the underlying function in a $default stub
verbatim, e.g., without renaming LVT entries or regenerating anonymous
objects. This commit introduces the same behavior in the JVM IR BE.
Fixes KT-36769.
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.
- Merge `duplicatingItemsSameHashCode.kt` and
`duplicatingItemsSameHashCode2.kt` into one test enabled on both
backends, and rename it to
`duplicatingItemsSameHashCodeFewBranches.kt`.
- Rename `duplicatingItemsSameHashCode3.kt` to
`duplicatingItemsSameHashCodeMoreBranches.kt`, and also enable it for
both backends.
- Use JVM_TEMPLATES/JVM_IR_TEMPLATES to check backend-specific behavior:
1) JVM IR does not optimize less than 2 branches by design
2) JVM IR does not generate duplicate branches, also by design
Related to KT-36846.
Steven Schäfer