interface I {
fun f(x: Int = 1)
}
class C(val y: I) : I by y {
// implicit `override fun f(x: Int) = y.f(x)` has a default value for `x`
}
-- the only case where a function with overridden symbols has defaults.
This allows us to not generate redundant immutable collection
stubs. The code to generate the immutable collection stubs does
not deal well with thinking that all external declarations
come from Java.
* Extract replacement of IrGetField/IrSetField into a separate
file-level lowering (should reduce the amount of work to linear in
the number of classes rather than potentially quadratic)
* Extract static backing field construction into JvmDeclarationFactory
and move that lowering after PropertiesToFields lowering to reduce
code duplication
May happen when a function in an `expect` class is aliased through an
`actual typealias`; the matching declaration is filtered out in
`ExpectedActualResolver.findActualForExpected` as it has no source.
Otherwise a local class in a field initializer or anonymous init block
is copied into each constructor of the containing class (because
InitializersLowering calls deepCopy).
Since the code structure no longer resembles the original source code
here, record a custom EnclosingMethod mapping before moving such
classes, and use it in codegen.
Necessary to support importing file classes annotated @JvmPackageName,
since the actual package fragment they are a part of has the name from
the `package` declaration.
Instead of calling enormously complicated
KotlinTypeMapper.mapToCallableMethod, where most of special cases are
handled in the IR backend via lowerings.
Without the `-Xmultifile-parts-inherit` mode for now.
This is implemented as follows: FileClassLowering collects information
about multifile parts and the corresponding facades, which a later
GenerateMultifileFacades phase uses to generate new IrFile instances and
add it to the module fragment that's being compiled.
Note that GenerateMultifileFacades is in the end of lowering phases
because delegates in the facade should be generated for all additional
functions generated by certain lowerings (default arguments,
JvmOverloads, etc.). If GenerateMultifileFacades was right after
FileClassLowering, they would still be generated, but we'd then process
them in lowerings mentioned above, which would result in duplicated
logic in the bytecode. There's a new bytecode text test which checks
that this doesn't happen for functions with default arguments.
Consider the following situation:
```
class Inv<T>
typealias A<K> = Inv<K>
typealias B<V> = Inv<A<K>>
fun <U> materialize(): B<U> = TODO()
```
Type `B<U>` is expanding to `Inv<Inv<U>>` and for this type `B<U>` and
`Inv<A<U>>` are abbreviated types, but due to a bug we forgot to make
substitution for `Inv<A<U>>` and were getting abbreviated type
`Inv<A<K>>` where `K` is a type parameter from the typealias declaration.
This bug didn't affect subtyping anyhow but the incorrect type was
serialized and caused problems during deserialization as there wasn't
`K` in deserialization context.
#KT-24964 Fixed
#KT-20780 Fixed
#KT-20065 Fixed
#KT-28236 Fixed
#KT-21775 Fixed
Most of these tests used this directive as a way to opt in to a new
language feature, and most of those features are already stable for a
long time, so no opt-in is needed. Some other tests used the directive
to opt out from a language feature, replace those by the `LANGUAGE`
directive. One test used the directive to test behavior that actually
depended on the API version; use `API_VERSION` directive there instead.
Mikhael Bogdanov