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
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
In reality plugin key was used only in two ways:
- found corresponding generator for member scope of generated class
- pass it to declaration origin so it can be read in backend IR plugin
Because of first usage plugin key was required to be an object, which
reduces functionality of second usage, because there was no way to
pass any additional info via key to IR (in future this usecase will be
covered with IR declaration attributes, but right now we don't have
them)
So now generator which created some class is now saved in its attributes
and plugins can use any keys they want. And since there is no other
usages of `FirExtension.key` it removed from FirExtension API at all
After that commit it's allowed to register any FIR plugin using
existing extension infrastructure (`-Xplugin` CLI argument,
plugin.xml for IDE plugins, etc)
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
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
Anastasiya Shadrina