In JS, RegExp can return a match before the specified start index,
if it has matched at that index, but it is in the middle of a surrogate
pair. Account for that when advancing to the next position after
a zero-width match so that it doesn't get to the middle of SP.
Currently JS/IR and WASM targets share this attribute.
This causes issues for HMPP projects on
Variant-resolution stage when both JS/IR and WAS published.
Given the fact that WASM compilation uses IR only it is logical
to exclude such attribute which should fix variant resolution in HMPP
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.
konstantin.tskhovrebov