This commit reverts 59e2101a25 partially,
leaving only the implementation of KT-25972 for JVM. The reason is that
we can't fully commit to stabilizing JS (and .kotlin_metadata) binary
metadata formats so much as to postpone any changes done to it for a
whole release year time. It's likely that we will need to update JS
metadata format incompatibly pretty soon, and with the scheme where we
can read the "current + 1" version, it'd require advancing the metadata
version by 2, which would break the nice property that the metadata
version (since Kotlin 1.4) is equal to the version of the compiler that
produced it.
See KT-25972
This reverts commit ba111d58ae.
The reverted commit only makes sense after a bootstrap step after
advancing the metadata version, which has not yet happened in master,
but did happen in 1.3-M2, where this commit was supposed to end up
It seems a candidate is added either when requiresExtensionReceiver is true and
receiver is not null or when requiresExtensionReceiver is false and receiver is null.
Consequently, f appears useless.
Move SimpleScopeTowerProcessor from TowerResolver into ScopeTowerProcessors.
Lift code duplicated in functions:
* ExplicitReceiverScopeTowerProcessor.simpleProcess()
* QualifierScopeTowerProcessor.simpleProcess()
* NoExplicitReceiverScopeTowerProcessor.simpleProcess()
into AbstractSimpleScopeTowerProcessor. Turn it into a function and call it
in the various context. Incidentally, now useless functions resolveAsMember()
and resolveAsExtension() are removed.
Increase performance by searching first SuccessOrFailure/runCatching/etc
in text of functions without return type.
Remove stdlib false positives, like success() & failure().
For catching extension, check also non-catching members.
Add "rename to *Catching" fix.
A new method has been added in the Android Gradle
plugin 3.3.0. This commit switches from ussing the
MergeResources task, and uses getAllRawAndroidResources
API instead.
Test: manually verified
Same as for primitives: inline lambda expects to see a boxed value,
so, even if an argument is a local variable, it can't be remapped,
because it contains unboxed representation.
Arguments are put on stack in the direct order, and then stored into
local variables for inlining in the reversed order:
<arg0>
<arg1>
<arg2>
store <param2>
store <param1>
store <param0>
Original value parameter types were taken in direct order, though.
JVM versions are increased in order to differentiate pre-1.3-M2 .class
files where signatures mentioning inline classes were not mangled. Other
versions are increased in case something similar will need to be
detected
Mikhael Bogdanov