If there is superinterface (more specifically, fun interface) in one
file with default suspend function, we lower the function, adding
continuation parameter. Then, when we compile another file with a child,
we generate a bridge to the default suspend function, which is already
lowered. So, we do not need to add the continuation parameter.
If the child is in the same file, then we add continuation parameter
after we create a bridge, so, AddContinuationLowering can encounter
bridges to suspend default functions in superinterfaces with
continuation parameter only in multifile examples.
#KT-47549 Fixed
Compared to FE1.0, instead of using UNRESOLVED_REFERENCE, a new
UNRESOLVED_IMPORT diagnostic is introduced. This is so that we can use a
different positioning strategy to highlight the last part of the import
if the entire import is passed.
Also, this change fixed some incorrectly rejected imports in FIR. Such
cases are covered the newly added test file staticFunAndPropertyImport.kt
This method was used for coercing `Long` values to JavaScript
`number`. However, it caused issues when `Long` values were
concatenated to a string (see KT-8666, KT-26706).
If we implement default function with default parameters in inline
class, the receivers will be added to parameter list
(see ac7538a269). But since they
are not present in source parameters, we should not count them when we
compute mask for default parameters.
#KT-49977 Fixed
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
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
The inliner uses module descriptors to figure out if it needs to
regenerate objects.
We should avoid the use of descriptors in the inliner, but this
works as a first quick fix.
Anastasiya Shadrina