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
This commit reverts f6571effcc and
reimplements the desired logic in another way.
In particular, we'd like these two conditions to hold:
1) only the release compiler with stable language settings (meaning,
language version is a released version of Kotlin and no experimental
features are enabled) should report errors when _reading_ pre-release
binaries.
2) the compiler should _write_ pre-release binaries only if language
settings are not stable, independent of whether the compiler itself
is release or not.
From these conditions it follows that we must use different logic to
determine how to behave when reading/writing pre-release binaries.
Namely, reading (in CompilerDeserializationConfiguration) now checks if
both the compiler is release and the language settings are stable, and
writing (in LanguageVersionSettings.isPreRelease) checks only that the
language settings are stable
Mikhael Bogdanov