For type parameters of generic properties,
`DeclarationDescriptor#getContainingDeclaration` must return
the property descriptor instead of the accessor function descriptor.
^KT-57436 Fixed
The reason #1 for this feature is that we want to test IdSignatures
generated for declarations. Currently, there is no (easy) way to ensure
that a change in the signature building logic doesn't cause any breaking
changes wrt klibs.
Now, most IdSignatures include hashed mangled names in them, so even if
we catch a regression where the included hash changes, there would be no
way of knowing immediately what caused it, unless we'd also have mangled
names in the expectations.
The reason #2 is to test the manglers themselves. Currently, there are
no tests for them. They heavily duplicate each other, this is already
causing issues (see KT-57427) that would be very hard to catch without
these tests.
^KT-58238 Fixed
Before this commit, for property candidates in K2 their types wasn't
inferred/susbtituted properly.
So, when candidate for fooBar.liveLoaded.invoke() was created,
the type of `fooBar.liveLoaded` was just X type parameter for which
there is no any `bar()` functions in its member scope.
While proposed semantics is a bit different from K1, where
both property and invoke candidates are united into common system,
it doesn't contradict to the specification (https://kotlinlang.org/spec/overload-resolution.html#callables-and-invoke-convention)
which says explicitly that invoke-convention should be desugared as
`r.foo.invoke()`, thus `r.foo` should be completed independently.
Also, this strategy supports some reasonable use-cases like KT-58259
while it's still a breaking change but for more artificial-looking
situations (see KT-58260) and should be passed through
the language committee.
The changes in stubTypeReceiverRestriction* tests looks consistent
because of how `genericLambda` now works
(with full completion of property call).
NB: The code is going to be red once KT-54667 is fixed and also there's
already similar diagnostic in K1 (INFERRED_INTO_DECLARED_UPPER_BOUNDS)
^KT-58142 Fixed
^KT-58259 Fixed
^KT-58260 Related
Use the same condition as in the already existing `createIrEnumEntry`
function (and as in psi2ir): enum class should be final unless there's
an enum entry with any declaration other than its constructor.
#KT-57216
We've muted some irText tests on JS in the previous commits because
test expectations in some tests are different when targeting JS.
AbstractKlibJsTextTestCase tests use a different logic:
they compare the dump of the deserialized IR with the frontend-generated
IR, not with the expectations in text files, thus muted tests weren't
actually failing.
Here we introduce a temporary fix, namely
a separate // IGNORE directive for klib tests.
When klib tests are moved to the new test infrastructure, there will be
no need to do this.
with dedicated opt-in language feature and special
annotation or module capability.
Not intended for a general use, solves specific K/N
scenario with interop libs.
#KT-55902 fixed
This change allows to revert adding `WITH_STDLIB` directive
to tests which happened at `a9343aeb`.
Co-authored-by: Alexander Udalov <Alexander.Udalov@jetbrains.com>
The expression needs to be resolved first to determine if there is a
receiver that needs to be extracted to a temporary variable. Also, the
special case for prefix increment/decrement on local variable without
delegates requires resolution to check if the variable is local.
^KT-56771 Fixed
^KT-56659 Fixed
See the relevant test at t/
estData/codegen/box/sam/contravariantIntersectionType.kt
After the previous commit, when generating a call for `doOnSuccess {}`,
we have a SAM type with removed projection Consumer<Any?>, while
real function type of the lambda is a bit different
(Function1<ConcreteType & ConcreteType2>).
While for me, that looks questionable, but in K1 it was effectively
resolved via the same implicit cast that on JVM is generated to an
INVOKEDYNAMIC that wraps initial function-typed value.
^KT-53552 Fixed
It would be more consistently to prohibit the behavior from the unmuted
test (see KT-52428), but it was decided to postpone the breaking change.
Unfortunately, it didn't work to make a test where for computing
star projections we would need to substitute other type parameters
because effectively, it's not allowed to have SAM conversion when
star projections/wildcard is based on a type parameter which bounds
use other type parameters.
^KT-53552 In progress
Beside some corner cases, it's already prohibited in K1 because
adaptation have a bit strange nature
(they don't represent any existing real function exactly)
^KT-55137 Fixed
In details, this commit changes the following:
- it converts FIR when without branches to empty IR block without when
- it doesn't drop empty else branches in when anymore
This feature is not needed because it is unconditionally disabled for K1
(because of not fully correct implementation) and unconditionally enabled
in K2 (K2 does not support old behavior)
^KT-38895
In FIR we desugar when with multiple conditions leading to same block
as tree of OR expressions
Given
```
when(some) {
"a", "b", "c" -> {}
else -> {}
}
```
actually desugared into
```
when(val <subj> = some) {
<subj> == "a" || <subj> == "b" || <subj> == "c" -> {}
else -> {}
}
```
There is a multiple ways of how we can organize such expressions in FIR
Previously it was just nesting-chain of OR expressions
While the most efficient way in terms of required stack depth is
a balanced tree
KT-53255
After we added "careful approximation of contravariant projections" in
584b70719e, some SAM conversions started to require an additional
implicit cast of the functional value before it is converted to the SAM
interface. The target type of this implicit cast was computed
incorrectly because it didn't contain nullability of the SAM type. This
could lead to a situation where a nullable value was incorrectly cast to
a non-null type, which caused a missing null check and NPE at runtime.
For example, let's consider the test `kt54600.kt`. SAM conversion
happens in the constructor call `J(filter)`. Before 584b70719e, the IR
for that argument was (irrelevant things are omitted for simplicity):
TYPE_OP SAM_CONVERSION type=Condition<String!>!
GET_VAR filter type=Function1<String, Boolean>?
After 584b70719e, the IR became:
TYPE_OP SAM_CONVERSION type=Condition<Any?>!
TYPE_OP IMPLICIT_CAST type=Function1<Any?, Boolean>
GET_VAR filter type=Function1<String, Boolean>?
Note the two changes:
* The resulting SAM type changed from `Condition<String!>` to
`Condition<Any?>`. This is exactly the point of the "careful
approximation" change, because just erasing the "in" projection from
the parameter type is incorrect, see the explanation for that change.
* The value is now implicitly cast to the _non-null_ function type
before it is SAM-converted. The presence of the cast is fine, but the
fact that it's to a non-null type is an oversight.
The target type for this cast is computed at
`KotlinType.getSubstitutedFunctionTypeForSamType` in psi2ir. Now it
extracts the nullability from the SAM type and retains it in the
resulting function type.
After this change, the IR for the argument becomes:
TYPE_OP SAM_CONVERSION type=Condition<Any?>!
TYPE_OP IMPLICIT_CAST type=Function1<Any?, Boolean>!
GET_VAR filter type=Function1<String, Boolean>?
Note that the target type is now flexible, as the resulting SAM type.
Another option would be to make it nullable, as the type of the
functional value, but there doesn't seem to be any difference.
#KT-54600 Fixed
In 1.7.20 we used the nearest Java-based receiver for such field
references in backend. Now we are using use-site receiver again,
it can lead to accidental usage of derived class property backing field.
This is effectively a revert of KT-49507 fix, see commits:
- fa914f20
- b0a6508d
#KT-54393 Fixed
#KT-49507 Planned
#KT-52338 Planned
For FE 1.0, we just change super qualifier symbol to
base class, if it's possible.
For FIR, we introduce using of super qualifier symbols for
field accesses and repeat FE 1.0 behavior here.
#KT-49507 Fixed
Sergej Jaskiewicz