We cannot be sure that we won't change behavior of these functions in
some corner cases, so only perform this optimization if the API version
specified by the user is not greater than the compiler's own stdlib
version it was compiled against. This is the same as the similar code in
the old backend in IntrinsicMethods.
In case of inline it should be same descriptor (except of fake override), In general case getter could be synthetic accessor and in such case it's not inline
With NO_LOCKS strategy we can easily end up in a situation when
constraint system for a generic call is built incorrectly,
producing flaky errors (or don't produce errors at all)
Now proper storage manager is injected for all cases except:
- IR
- Codegen
- Serialization plugin
- Fake local objects
Most likely, NO_LOCKS strategy for these cases is fine as at that point
the compiler works in one thread
#KT-34786 Fixed
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;
Namely, anonymous objects defined in lambdas that have all captured
variables as loose fields instead of a single reference to the parent.
The question is, when a lambda inside an inline function defines an
anonymous object, and that object is not regenerated during codegen for
the inline function itself, but then has to be regenerated at call site
anyway, do we use an outer `this` or loose capture fields? For example,
before KT-28064:
inline fun f1(g: () -> Unit) = object { g() }
// -> f1$1 { $g: () -> Unit }
inline fun f2(g: () -> Unit) = f1 { object { g() } }
// -> f2$$inlined$f1$1 { $g: () -> Unit }
// f2$$inlined$f1$1$lambda$1 { this$0: f2$$inlined$f1$1 }
inline fun f3(g: () -> Unit) = f2 { object { g() } }
// -> f3$$inlined$f2$1 { $g: () -> Unit }
// f3$$inlined$f2$1$1 { this$0: f3$$inlined$f2$1 }
// f3$$inlined$f2$1$1$lambda$1 { this$0: f3$$inlined$f2$1$1 }
After KT-28064:
inline fun f2(g: () -> Unit) = f1 { object { g() } }
// -> f2$$inlined$f1$1 { $g: () -> Unit }
// f2$1$1 { $g: () -> Unit }
inline fun f3(g: () -> Unit) = f2 { object { g() } }
// -> f3$$inlined$f2$1 { $g: () -> Unit }
// f3$$inlined$f2$2 { ??? }
// f3$1$1 { $g: () -> Unit }
Should `???` be `this$0: f3$$inlined$f2$1` or `$g: () -> Unit`? This
commit chooses the latter for KT-28064 bytecode and keeps `this$0` when
inlining the old bytecode.
returning Unit. Because on resume the result might be not a Unit if
the callee is tail-call and its callee return something different from
Unit and suspends.
Luckily, we generated ReturnsUnitMarker on such calls in all release
versions since 1.3. So, even if the code is inline and generated by
older versions, it will still work correctly.
The only version of the compiler, which does not generate the markers,
is 1.3.60-eap-76, because we did not generate the markers since
cc06798e2c. But I think, this is not
an issue.
#KT-34703
Take branching and method calls into account when finding the line
number of the continuation. If there is no line number before
branching instructions or method calls, the following code is
still on the line of the suspend call itself.
This fixes a couple of issues with incorrect line numbers for
multiple throws on the same line or multipe suspend calls on
the same line.
In addition, it avoids the need to spam the method node with
repeated line number instructions in the IR backend.
With the mangling added in 488418d960, there's no longer any risk in
writing "special" function name ("<anonymous>" in this case) to the
local variable table.
#KT-34356 Fixed
Given the strict pattern-matching in the inliner, this is the only way
to make it not crash when attempting to inline these stubs. Note that
the IR backend does not currently use the inliner's default method stub
handling; the crash only occurs when a module compiled with the non-IR
JVM backend is attempting to call an inline function with default
arguments defined in a module that was compiled with the IR backend.
There was a problem with `reportDiagnosticOnce` method which was
called, for example, to report diagnostics about experimentalities. It
was crucial for code as in the issue (KT-34204).
The whole complexity was "count of experimental diagnostics" multiply
"count of all diagnostics" multiply very large constant. Almost on
each `reportDiagnosticOnce` method `readonlyView()` was called which
in turn called computation of cache. During cache computation we were
iterating through the all diagnostics and also were using
KotlinSuppressCache, which is not very fast.
#KT-34204 Fixed
This fixes the problem where compiling a class initializer that contains
a call to an `assert`ing function in a separate module causes the
assertion to always be enabled (i.e. the attached test used to fail in
CompileKotlinAgainstInlineKotlin mode).
Generally, using state.classFileVersion would be enough because we
report an error when inlining bytecode into a class file with a lower
target version (see INLINE_FROM_HIGHER_PLATFORM). However, we take maxOf
with the original version of the class file, _just in case_ the user has
suppressed this error (for example, to workaround some other corner case
in the compiler).
#KT-30744 Fixed
CheckLocalVariablesTableTests will now check the validity of
the locals table against types of locals computed based on the
bytecode.
These checks and the new destructuringInFor test act as a
regression test for the changes in
https://github.com/JetBrains/kotlin/pull/2613
These checks also caught a similar issue for destructuring
lambda parameters, where the local is introduced before the
value has been written to the local slot. This change also
fixes that.
Finally, this change fixes the asmLike tests to correctly
look up the name of parameters in the locals table.
If the delegated property operators involved are inline, and delegated
property metadata parameter is not used (which is often the case, e.g.,
'lazy'), we can skip those properties in metadata generation.
NOT implemented: special case when only 'kProperty.name' is used by the
corresponding delegated property operators.
Also a sneak fix for KT-34060.
If the scope for a local variable is started before a value
has been written, another value from a previous use of the local
slot can be present. That value could have a different type which
would lead to weird debugging situations and also leads to other
tools (such as D8) rejecting the locals information as it is
invalid.
Fixes KT-33959.
Alexander Udalov