Commit Graph

4 Commits

Author SHA1 Message Date
Dmitry Petrov
c165b8d55c JVM: Update IR bytecode text and signature tests 2020-05-20 07:19:30 +03:00
Dmitry Petrov
cf70c83ab7 JVM: Update tests 2020-05-20 07:19:29 +03:00
pyos
82fb5c4d19 JVM_IR: move lambda captures to end of signature when inlining
For example, a lambda `{ param -> captured }` of type `E.(T) -> U` will
be transformed by LocalDeclarationsLowering into a private static method

    fun f$lambda-0($this: E, $captured: U, param: T) = $captured

The reason for such an ordering is that a lambda looks the same as a
local function, and local function can have default arguments, and those
arguments can reference captured variables; thus, captured variables
must come before actual declared arguments.

However, this is not the order that the inliner wants. Moreover, since
it was written to handle lambdas represented as `invoke` methods of
anonymous objects, it does not expect the actual callable method to have
any parameters corresponding to captured variables at all. This results
in it attempting to generate a temporary node with descriptor

    (LE;LU;LT;LU;)LU;

while still using locals 1 and 2 as `param` and `$captured` respectively.
In the example above, this is not critical, as they both have reference
type and the lambda will eventually be pasted into a different node
anyway; however, if it happens that one of them is a primitive, or both
are primitives of different types, the bytecode will use incorrect
instructions, causing verification errors. The correct descriptor is

    (LE;LT;LU;)LU;
2019-11-11 13:46:42 +01:00
Dmitry Petrov
08abf5f2a2 Specialize unsigned range and progression iterator calls 2019-01-16 11:00:23 +03:00