For properties which delegate to other property via the getValue
operator from stdlib (see KT-39054), we generate `$receiver` field which
stores the receiver of the property reference used in the delegate. The
problem was that this backing field was missing `correspondingProperty`.
It's needed because it is used as a map key to store static fields in
`JvmCachedDeclarations.getStaticBackingField`. If it's null, accesses to
the static $receiver fields are not remapped correctly in
`RemapObjectFieldAccesses` and
`MoveOrCopyCompanionObjectFieldsLowering`, which led to ICCE or NSFE.
#KT-49793 Fixed
Elvis now is being resolved a bit differently and in case
of inconsistent types, the while expression has error type,
but no diagnostic is reported since the element has no valid source element
When one sets the source
https://github.com/JetBrains/kotlin/commit/817316cdc93457c1de7cf10c3b422e3a4b486e5b
it brings back the issue KT-45989 that was effectively unresolved but hidden
due to diagnostic loss
^KT-45989 Open
Some existing tests start failing after previous commits adding @Exact
attribute to `?:`
They have a form:
var x: String? = nullable()
if (x == null) {
x = nullable() ?: "" // considering @Exact the whole elvis is inferred to nullable from expect type
}
x.length // should be smart cast
Previously, it was obtained from expected type of a variable being assigned,
but it's better to use the type of resulting expression
Initially this part was brought in 4ab0897d7d,
but as we see in commit message and tests it was all about unit-coercion
Kotlin's compilation task outputs usually contains a lot of small files,
which is not so performant to copy as-is into new location. In this
change coping was replaced by using zip archive with no compression.
From my test I see around 2x performance improvement on doing task
outputs snapshot.
Further optimizations will be done via separate issue as they are
non-trivial and requires some changes on the compiler side.
^KT-49782 Fixed
Avoid adding ConfigurableFileTrees to sources as that causes
individual *.java files to be evaluated as sources roots. To
pass the dependency info, manual dependsOn is used, but in the
future SourceRoots should be fixed to carry the dependency info.
The implementation was keeping delayed jobs in std::set sorted
only by the scheduled execution time (in microseconds since epoch).
So two jobs submitted to a worker and having the same scheduled time
were considered equivalent by the set, and one of them got lost.
Fix this by using std::multiset instead of std::set.
If compiler plugin removes source files between rounds of incremental
compilation, it may result into incorrect state of stubs. But rebuilding
stubs may require services available in UI mode only and cause
compiler failure.
This commit contains work-around allowing to avoid incorrect state of
stubs.
#KT-49340 Fixed
Mikhail Glukhikh