- The new `LLSealedInheritorsProvider` is based on the previous
sealed inheritors provider implementation in the IDE. It uses the
new direct inheritors provider and the module dependents provider to
implement the same functionality that was previously confined to the
IDE. With this design we avoid duplication of complex logic such as
the KMP handling in `searchInheritors`.
- The implementation is designed to work in the production Standalone
mode and the aforementioned services have already been implemented for
Standalone in prior commits. Now we can get rid of the problematic
`SealedClassInheritorsProviderForTests` and tests should more closely
match production behavior.
- In IDE mode tests, `LLSealedInheritorsProvider` is used with
Standalone Analysis API provider implementations. This is in line with
the rest of the test infrastructure, where Standalone AA providers are
generally used, as IDE providers aren't available.
- `KotlinSealedInheritorsProvider` is made obsolete by the common sealed
inheritors provider.
^KT-66013 fixed
^KT-64505 fixed
It's caused by checking the return type of an inherited property.
toConeKotlinTypeProbablyFlexible() returns an error type when the
type ref is unresolved instead of throwing.
This "breaks" some override checks and in the added test, it leads
to an additional candidate being created for a synthetic property.
However, the candidate has applicability K2_SYNTHETIC_RESOLVED
and gets filtered out because the real property has a higher
applicability.
#KT-66392 Fixed
`StubBasedFirTypeDeserializer` handles function parameter with a
receiver with a special exception, which sets it as
`ExtensionFunctionType`, but skips setting special function kinds for it
even when the function parameter type is a special function kind. This
drops `Composable` annotation from a lambda expression if the function
parameter taking the lambda expression as an argument has a receiver,
which causes a severe CodeGen error for Compose app on K2 Android
Studio.
^KT-66526 Fixed
In fact the latest compiler (neither K1 nor K2) does NOT report an error
here, see KT-66522. The error was there in the diagnostic test because
the test used custom code which invoked parts of the old JVM backend to
report signature clash errors.
The issue is rather minor and is present since 1.5, so to reduce
confusion, the test is deleted.
#KT-66522
In this commit, tests where backend diagnostics were reported correctly
are being moved.
FirScopeDumpHandler was added to FIR diagnostic tests with JVM backend
to support `SCOPE_DUMP` in `overridesBuiltinNoMagic.kt` and
`charAtAndOverload.kt`.
This is basically a copy of the test
`diagnostics/tests/j+k/primitiveOverrides/triangleWithFlexibleTypeAndSubstitution4.kt`.
The diagnostic version of the test is not removed because it has
frontend-specific diagnostics `FIR_DUMP` and `SCOPE_DUMP`.
This test is copied to make it clear that it actually passes in K1, and
new errors in K2 here are technically a breaking change, see KT-66529.
The error CONFLICTING_INHERITED_JVM_DECLARATIONS was present there only
because diagnostic tests used parts of the old JVM backend to report JVM
backend diagnostics.
#KT-66529
- `typeParameterWithTwoBounds.kt` is already present in
`diagnostics/testsWithJvmBackend/duplicateJvmSignature/erasure/`.
- `clashWithCompanionObjectField.kt` is already present in
`codegen/box/fieldRename/jvmFieldNoClash1.kt`.
- `jvmFieldAndJavaGetter.kt` is already present in
`codegen/box/jvmField/noClashWithInheritedJavaMethod.kt`.
In case of two latter tests on JvmField, there's (correctly) no error
reported in JVM IR, which is why those are box tests.
Foreign values (such as '_DebugLabel' properties contributed by the
debugger) don't have a parent (or a valid source element in general).
^KTIJ-27382 Fixed
They are mostly necessary for argument mapping during resolution.
To support a couple checkers, we transform named args for varargs
into "fake" spread expressions.
Other than that, named arguments aren't needed for anything and often
lead to bugs where we forget to unwrap them for something, so it's
better to get rid of them.
#KT-66124
It's not really necessary if the information about if the lambda was a
trailing lambda can be directly saved in FirAnonymousFunctionExpression.
Removing the FIR node uncovered a couple of bugs
(UNINITIALIZED_ENUM_ENTRY, ERROR_IN_CONTRACT_DESCRIPTION) that were
caused by assuming that a lambda is always a trailing lambda.
#KT-66124
Instead, it should happen during BODY_RESOLVE phase.
This fixes KT-66150. The problem was, that `super<B>.f()` expression
in delegated constructor call was transformed during TYPES phase,
and type transformer has no special logic for allowing bare types in
super qualifiers, like the one in expressions transformer (see
`org.jetbrains.kotlin.fir.resolve.transformers.body.resolve.FirExpressionsResolveTransformer.transformSuperReceiver`).
As a result, `B` without type argument leads to
WrongNumberOfTypeArgumentsError.
It looks incorrect that expressions in constructor call resolved
during TYPES phase, so skipping transformation of
argument list seems like the best solution here.
^KT-66150 Fixed
In most affected tests, the backend diagnostic such as "conflicting JVM
signature" or "accidental override" is directly caused by some already
existing error reported by frontend, so it doesn't make sense to check
backend diagnostics there.
Tests where that was not the case were moved/copied to
`testsWithJvmBackend`.
All of these tests were actually copied to `testsWithJvmBackend` in
866f188120, but it's unclear why they were copied instead of moved. The
test runner for `testsWithJvmBackend` correctly runs the compiler
pipeline and obtains errors reported by the backend, as opposed to the
common diagnostic tests which have a very custom code, using parts of
the old JVM backend, to obtain these diagnostics.
- `require.kt` was added to check JVM accidental override diagnostic
when using the "traits with required classes" feature, which was
removed a long time ago.
- `withErrorTypes.kt` was testing conflicting JVM declarations error (a
backend diagnostic) in presence of error types -- not very useful
scenario because the backend is not run when there's a frontend error.
The following tests are failing with exceptions and will be fixed in the
following commits
j+k/testKjkPropertyAndExtensionProperty.kt
j+k/testKjkImplicitReturnType.kt
#KT-62118 Fixed
lambdaParameterForBareTypeEarlyFixationAffectsBehavior.kt
should show in the future commits how early variable fixation
necessary for bare type information might affect inference results
^KT-64840 Related
Right now, during the process of inlining, the compiler erases types.
Because of that, we can end up with some random type
(for example, `Any`) where the concrete type was
expected (for example, `Int`). Compiler must insert a cast in the
required places.
#KT-66017 Fixed
- We can also soft-reference the `KtFile` key. Chances are, if the
`KtFile` can be garbage-collected, we do not need a `FileStructure`
instance for it either.
^KT-65978 fixed
Dmitriy Novozhilov