Assuming Java class `Super` has a protected `getName` method and a
public `setName` method.
Then, in a subclass of `Super`, FE1.0 allows calls to `setName` via the
property syntax if the property is protected and invisible due to
dispatch receiver is not `this` or `super`.
Previously actual value was dependent on the order of calls to `updateJvmTarget` and `configureJava9Compilation` in build script that may lead to inconsistencies
`compileOnly` configuration is unresolvable, and it's more preferable to create new configuration that extends from it rather than making it resolvable
val y = 1
object { val x = y }
->
class XKt$1(`$y`: Int) { val x: Int = `$y` }
Note that `$y` is not stored in a field because it's not used outside
the primary constructor.
One exception is captured inline parameters on the JVM backend, as the
bytecode inliner uses field assignment instructions (setfield) to locate
them; removing the field is thus not possible.
It won't fix KT-48181 completely, but it will allow to create such annotations
if all value arguments are specified.
For the full fix, we need to read default annotation values from classfiles in jar.
#KT-48181 In progress
TL;DR, before we were emitting this JS code:
Object.defineProperty(Base.prototype, 'bar', {
configurable: true,
get: Base.prototype._get_bar__0_k$,
set: Base.prototype._set_bar__a4enbm_k$
});
Now we emit this code instead:
Object.defineProperty(Base.prototype, 'bar', {
configurable: true,
get: function () {
return this._get_bar__0_k$();
},
set: function (value) {
this._set_bar__a4enbm_k$(value);
}
});
This fixes the issue where if we had a @JsExport'ed base class with a
public property overridden in a non-exported derived class, we couldn't
access that property from JS if we were given an instance of
the derived class.
#KT-41912 Fixed
Call mather relies on that BuiltIn package fragment implement specific
interface `BuiltInsPackageFragment` which was missed. Make sure that
BuiltIn module's package fragments implement that interface.
Fix progression optimizer symbols resolve in JS & WASM IR BE
When in 'lenient' or 'classpath' mode, Gradle will catch exceptions
during project evaluation and collect them into the
'ClassPathModeExceptionCollector'.
Running checks on the project after evaluation should only happen
if the project is properly configured (aka no such exceptions collected)
to prevent false positive error reports (that will then fail
the Gradle process and swallow the real cause)
^KT-48823 Verification Pending
Workers usually execute later than task action and does not raise
exception to the task. Such behaviour skips task outputs restoration to
the pre-execution state.
Kotlin compiler on incremental compilation error leaves 'dirty*' files
in the build output, forcing Gradle to run non-incrementally on the
next build. Fixed it by moving task outputs reset logic into worker as
well.
^KT-46406 In Progress
Tianyu Geng