Previously @EnhancedNullability for IR type was added if only there wasn't
an @FlexibleNullability annotation, which is inconsistent with K1
behavior
^KT-65302 Fixed
In some cases we transform flexible type into non-flexible during
enhancement, but don't add `@EnhancedNullability` attribute to them,
which breaks consistency with K1 on IR level
This commit fixes it
^KT-65302
This commit is intended to deal with inconsistency in K1/K2
star projection handling.
K1 star projection includes a 'type' property.
This type from a star projection can be used for relevant
functions / properties return types,
and already includes some approximation for recursive generics.
In contrast, K2 star projection is an object,
and return types of relevant functions / properties are
represented as captured types.
To prevent recursion in them in recursive generic case,
this commit includes additional replacement of their type arguments.
See more details in added comments.
#KT-65057 Fixed
When a type annotated with @PurelyImplements (explicitly or implicitly)
inherited some methods from a java supertype and the purely implemented
Kotlin supertype, it was inconsistent which of the signatures the
intersection override would have (with or without flexible types).
This commit adds support for the enhancement of intersection overrides.
If one of the overridden methods has non-flexible types, the enhanced
method will have non-flexible types.
This fixes some false negative nullability type mismatches.
#KT-59921 Fixed
This fixes a bunch of missing overridden symbols in IR.
This is also required for fixing KT-59921 in the following commit
where we need to keep all overridden symbols of intersection overrides
so that we can enhance them properly.
#KT-57300 Fixed
#KT-57299 Fixed
#KT-59921
#KT-57300
#KT-62788
#KT-64271
#KT-64382
We drop Kotlin function 'remove' or 'getOrDefault' from JvmMappedScope,
if it has platform-dependent annotation, and the bound Java class scope
does not contain a function with the same signature.
#KT-57268 Fixed
NB: in order to produce correct IR origins, the source element kinds for
some FIR elements has been changed. As a side effect, mapping PSI to FIR
slightly changed: namely, for `a[b]++`, `a[b]` used to be mapped on
`set` call or callable reference, but now it is mapped on `get` call.
^KT-61891: Fixed
^KT-64387: Fixed
This origin was set somewhat arbitrarily.
It actually only makes sense for `IrCall`s to property getters.
There were no places in lowerings that checked `IrGetField` expressions
for this origin value.
^KT-62500 Fixed
While not beeing final solution, this is closer to what
we want to have in the end. Enabling on non-JVM targets
would help better testing.
Enabling in JVM is now not possible yet, as some of the bugs are
not fixed yet (check KT-61360 for details)
^KT-62476
We don't have true flexible types in the IR, but we approximate it with
internal type annotations, such as FlexibleNullability,
FlexibleMutability, RawType. These annotations are then handled
specially in JvmIrTypeSystemContext, which can construct a fake flexible
type so that type checker on IR types would behave exactly as on
frontend types.
As shown in KT-63441, one instance of flexible types where flexibility
was lost during conversion to IR is Java array/vararg types. It's
necessary to support it so that IR fake overrides could be constructed
correctly, because IR fake override checker requires parameter types to
be equal. So this change introduces another internal type annotation,
FlexibleArrayElementVariance, which is only applicable to types with
classifier kotlin/Array, and which signifies that the annotated type
`Array<X>` should rather be seen as `Array<X>..Array<out X>`.
#KT-63441 Fixed
#KT-63446 Fixed
```
interface A {
fun <T> foo(): T
}
class B(val a: A) : A by A {
generated fun <T'> foo(): T' {
return a.foo() // <------
}
}
```
There was a problem that type of generated delegated call used
an unsubstituted type of the original delegated declaration, which led
to a situation when (see example) type of call `a.foo()` was not `T'`
but `T`, which led to incorrect IR and further exceptions on backend
^KT-64257 Fixed
^KT-64284 Obsolete
Rework rendering of kt-like dump and signatures dump in order to avoid
unstable blank line between declarations of the same level:
1. No blank line for the first declaration inside the member scope of
the class.
2. Always a single blank line between each two subsequent declarations
inside the member scope of the class.
Making enum class-related tests unmuted requires implementing
a special "compatibility" mode for IR tree dumper to filter out
fake override declarations leaking from java.enum.Enum and
kotlin.Enum (JVM-only) classes.
1. Local declarations don't participate in IR-linkage, because they
can be referenced only inside the same body -> can be dropped
from IR text tests.
2. Mangled names for private declarations computed by descriptors/fir
are actually not used anywhere (they are recomputed by IR
immediately before serialization of IR). But sometimes such
mangled names diverge between K1 and K2 -> don't check them, but
always check mangled names computed by IR even for private
declarations.
3. Also: Drop DUMP_LOCAL_DECLARATION_SIGNATURES test directive.
^KT-57428 Obsolete
^KT-57430 Obsolete
^KT-57434 Obsolete
^KT-57778 Obsolete
^KT-57775 Obsolete
We plan to disable computing full mangled names of declarations in all
manglers except the IR mangler (see the subsequent commits).
From now on, in irText tests we dump only the following mangled names:
- Full mangled names computed using the IR mangler
- Signature mangled names computed using the Descriptor mangler
- Signature mangled names computed using the IR mangler
- Signature mangled names computed using the FIR mangler
Here by a full mangled name we mean the mangled name of a declaration
computed using the `MangleMode.FULL` mode. Those mangled names include
the mangled names of the declaration'a parents.
By a signature mangled name we mean the mangled name of a declaration
computed using the `MangleMode.SIGNATURE` mode.
These mangled names are used to compute an `IdSignature` for
the declaration, hence the name.
Types based on type parameters which have both hasEnhancedNullability
and hasFlexibleNullability were incorrectly converted to IR: only
`@EnhancedNullability` annotation was added to the IR type. This means
that the nullability of the type started to matter, which is incorrect
because the type is supposed to be flexible.
This backfired in the IR fake override builder mode, where nullability
of methods inherited from both Kotlin maps and Java maps clashed, which
resulted in the exception from FakeOverrideRebuilder.
If the type is both flexible and enhanced, we're now adding
`@FlexibleNullability` to the IR type. Note that `@EnhancedNullability`
is not needed because it only affects primitive types which need to be
handled as wrapper types on JVM, but `@FlexibleNullability` already has
that effect.
IR still slightly differs from K1 for collection subclasses, which can
be seen for example in the changed IR text tests. This is to be
investigated later.
The change in tests is needed because the `kt48495*.kt` tests are now
passing on K2 in the IR fake override builder mode, while failing on the
vanilla K2.
This is related to KT-61370 but does not entirely fix it, although
curiously it fixes all remaining tests which were muted because of it.
Previously, creating a declaration with Fir2IrCallableDeclarationsGenerator/
Fir2IrClassifiersGenerator didn't guarantee that this declaration will
be actually added to the list of parent class/file declarations, which
lead to situations when FIR2IR created some declarations in the air
(mostly fake-overrides)
It's effectively a breaking change (^KT-62558)
K2 assigns flexible type to all static fields (from Java) and, for example,
`String? becomes String unlike K1. It affects IR signature generating.
That's why signature dump is disabled for some tests.
^KT-57811 Fixed
^KT-61786 Fixed
Dmitriy Novozhilov