See the comment at updateSubstitutedMemberIfReceiverContainsTypeVariable
It became necessary after delegate inference is rewritten, since before
that happened, stub types were being left there and FIR2IR handled
them accidentally properly because stub types are equal to anything.
But that wasn't really correct even there because stub types are not
intended to leak out of the FIR
^KT-61060
The main idea is getting rid of stub types and using just type variables
See more detailed description at docs/fir/delegated_property_inference.md
The problem with stub types is that they need really special treatment
in many places, and on the other hand, there are no clear contracts on
how they should work (that regularly leads to bugs like KT-59529)
^KT-61060 Fixed
^KT-61075 Fixed
^KT-61077 Fixed
^KT-59529 Fixed
^KT-61633 Related
^KT-61618 Related
^KT-61740 Related
^KT-59107 Related
^KT-61747 Related
^KT-61077 Related
^KT-61781 Related
Optimization in 2439c22ff6 introduced an array `absentArguments` with
default values of all parameter types, which is copied in `callBy`
instead of being recomputed each time. Unfortunately, its size was
computed incorrectly: `maskSize` should only take into account
value parameters (see the `parameter.kind == KParameter.Kind.VALUE`
check in `callBy`).
This led to an issue where if the function had 32 * N value parameters
and 1 receiver parameter, `maskSize` was greater by 1 than expected,
which caused an exception due to mismatching argument array sizes.
#KT-61304 Fixed
fixup! Fix `isKotlinFunctionWithBigArity` function
Fix `isKotlinFunctionWithBigArity` function
Previous implementation could return false positive results, e.g. for
class named `abacaba.kotlin.Function42`
^KT-61548: Fixed
Merge-request: KT-MR-11928
Merged-by: Vladislav Grechko <Vladislav.Grechko@jetbrains.com>
The only case when erasure matters in a context of materialization of
`PromisedValue` is when the type is a type parameter which upper bound
is an inline class. Since `PromisedValue::materializeAt` is a hot spot
and `eraseTypeParameters` is an expensive operation, we should not do
type erasure in other cases.
If some function is not fake-override, then its type should be just
default type of containing class
For fake overrides the default type calculated in the following way:
1. Find first overridden function, which is not fake override
2. Take its containing class
3. Find supertype of current containing class with type constructor of
class from step 2
^KT-60252 Fixed
single builder parameter
single postponed type variable
single origin of type information
relevant issues:
KT-60719
KT-60720
KT-60855
KT-60877
KT-60880
Currently, there is only attribute `ExpectForActualAttributeKey`
where mapping is stored only for source declarations with `actual`
modifier. But we need mapping of all class members, including classes
which were actualized via `actual typealias` or fake override members.
This data will be needed for the annotation checker in subsequent
commits.
^KT-60668
^KT-60936
Disabling the language feature is supported,
otherwise there are too many tests that
would need to be updated to account for
K2's inability to do it.
The `ifConstVal.kt` test is deleted,
because now it must also be ignored in K2,
and since it is ignored for both the
frontends, and the ignored backends
include all the target backends, this test
is basically unused.
Note that now both the frontends report
`CONST_VAL_WITH_NON_CONST_INITIALIZER`.
for `condition`.
^KT-55196 Fixed
This fixes a KMP issue where IrActualizer would add duplicate
fake overrides because the parent class would have both the getter
and the synthetic property in its list of declarations.
Now, the synthetic property fake overrides are still generated and
cached in the Fir2IrDeclarationStorage, but not added to the class.
#KT-60854 Fixed
This change covers the case where some f/o was generated in common module
and it is referenced in platform code. But signature of this f/o may be
different in different modules because of e.g. actualization of value
parameters with actual typealias
^KT-60850 Fixed
Consider the following example from
`extensionLambdasAndArrow.kt`:
```
val x4: String.() -> String = if (true) {
{ str: String -> "this" }
} else {
{ str: String -> "this" }
}
```
Because of
`coerceFirstParameterToExtensionReceiver`
the given lambdas must be of the type
`String.() -> String`, but because of a bug
they are `String.(String) -> String`. At the
same time, during inference their expected
types are, indeed, calculated correctly as
`String.() -> String`.
^KT-59394 Declined
(no more compiler crashes, #potential-feature)
For annotations defined in Java, IrProperties do not contain initializers in backing fields,
as annotation properties are represented as Java methods.
Therefore, it is not possible to use initializer values as default values for constructor parameters.
However, K2 stores default values in annotation's constructor parameters,
so it is possible to fix this issue if they're properly transfered to the IR
and inspected in JvmAnnotationImplementationTransformer
#KT-47702 Fixed
#KT-47702 tag fixed-in-k2
By ignoring type parameters. Since type parameters in annotations are a
very limited feature, their sole use is to be able to specify them as
KClass argument: annotation class Foo<T: Any>(val bar: KClass<T>).
Since we can encounter type param only as a KClass type argument (and
never as a property type), simple approach of ignoring them works fine.
In that case, since we simply copy property types to synthetic
implementation class, its properties in IR start look like this:
annotation class FooImpl(override val bar: KClass<T of Foo>). This IR
seems to be not completely correct, since FooImpl.bar type contains T of
Foo param, which is out of its scope. However, so far I didn't
encounter any problems with this during testing and after MR discussion
this approach has been considered possible.
#KT-59558 Fixed
#KT-59036 Fixed
Dmitriy Novozhilov