It's expected to partially mimic the behavior of what
previously was called builder inference, but with more clear contracts
(documentation is in progress, though)
See a lot of fixed issues in the later commits with test data,
especially [red-to-green]
^KT-59791 In Progress
It affects the `is IrGetField` check in
TypeOperatorLowering.computeNotNullAssertionText, which leads to missing
NPE messages when accessing backing fields of public properties.
#KT-64615
^KT-59938 Fixed
Review: https://jetbrains.team/p/kt/reviews/13760
After this patch:
> The /compiler/testData/diagnostics/tests/multiplatform/topLevelFun/conflictingImplDeclarations.kt test:
Fixed
> The /compiler/testData/diagnostics/tests/multiplatform/headerClass/expectDeclarationWithWeakIncompatibilities.kt test:
Declarations are in the same module. `PACKAGE_OR_CLASSIFIER_REDECLARATION` is reported anyway
> The /compiler/testData/diagnostics/tests/multiplatform/java/varPropertyAgainstJavaGetterAndNonFinalField.kt test:
Expect-actual matcher doesn't match fields in K2 https://youtrack.jetbrains.com/issue/KT-63667 => green code
> The /compiler/testData/diagnostics/tests/multiplatform/java/propertyAgainstJavaPrivateFieldAndPublicMethod.kt test:
Expect-actual matcher doesn't match fields in K2 https://youtrack.jetbrains.com/issue/KT-63667 => green code
> The /compiler/testData/diagnostics/tests/multiplatform/java/implicitJavaActualization_multipleActuals.kt test:
K2 doesn't have implicit Java actualization. And PACKAGE_OR_CLASSIFIER_REDECLARATION is reported anyway
> The /compiler/testData/diagnostics/tests/multiplatform/java/propertyAgainstJavaPublicFieldAndPublicGetter.kt test:
Expect-actual matcher doesn't match fields in K2 https://youtrack.jetbrains.com/issue/KT-63667 => green code
> The /compiler/testData/diagnostics/tests/multiplatform/actualClassifierMustHasTheSameMembersAsNonFinalExpectClassifierChecker/injectContextReceiverOverload.kt test:
Context receivers are not supported in expect-actual matcher. https://youtrack.jetbrains.com/issue/KT-61447
And K2 reports another error right now anyway
Motivation: AMBIGUOUS_ACTUALS can't be reported on frontend (because it
requires expect to actual mapping, but the mapping is only available on
backend)
In scope of KT-59938
Review: https://jetbrains.team/p/kt/reviews/13760
^KT-58765
Now that JDK 21 was released as stable, we can remove separate test
configurations for testing the compiler with JDK 21 and reintegrate
the corresponding test data into standard test configurations.
^KT-58765
Now that JDK 21 was released as stable, we can remove separate test
configurations for testing the compiler with JDK 21 and reintegrate
the corresponding test data into standard test configurations.
Instead, use specific resolution mode handled by call completer.
Mostly, it's done for simplification of PCLA implementation because
otherwise we would need to track how PCLA inference session and the
one for augmented should be combined.
But just independently of this, not using inference session here,
it looks just simpler.
^KT-59791 In Progress
Initially, it was a bug caused by unfortunate copy-paste, but there were
no tests for this because mostly `delegation` operators are functions
But after PCLA is implemented, many tests start failing
For example, FirPsiOldFrontendDiagnosticsTestGenerated.Tests.BuilderInference.OneParameter.OneTypeVariable.OneTypeInfoOrigin.TypeInfoSinks.testImmutableProperties
^KT-59791 In Progress
This was never semantically correct, but was not important
before KT-63644, as they were immediately dropped after that anyway.
After KT-63644, they were used to compute fake overrides inside them,
which were later matched against actual class, which can
produce false-positive matching errors.
^KT-64835
It was decided to leave this code as is, because supporting
it would probably require introducing Implication-statements,
but this is not a good-enough use-case for such work.
Before this change `ARGUMENT_TYPE_MISMATCH` would complain that
`Y` "is not a subtype of" `Inv<Y>`, because the function would only
check immediate bounds of the type parameter `Y`. `chosenSupertype`
would be `X`, not `Inv<out kotlin/String>`.
^KT-60056
`invoke()` function of functional types is always defined
in such a way that its explicit receiver comes as the first
value parameter. Extension-function types contain the very
same `invoke` function, they just additionally have the
`@ExtensionFunctionType` annotation.
In the related test there is such an `invoke` function and
in the presented call its explicit receiver is the anonymous
function `fun Int.() = 1` itself. So the safe-checked `1`
^KT-60056
Replace every property with its getter and setter. This is needed
because later on, JVM backend assumes that all properties have been
lowered (by JvmPropertiesLowering) to this state.
#KT-64116 Fixed
This is already the case for Kotlin/JS.
This is required for fixing KT-63670: `linkViaSignatures` implies that
`SymbolTable` is used in FIR2IR, and in case if two declarations
have the same `IdSignature`, we have a crash in FIR2IR:
exception: java.lang.IllegalStateException: IR declaration with
signature "/foo|foo(){}[0]" found in SymbolTable and not found in
declaration storage
If we're not using SymbolTable, FIR2IR finishes successfully, and we can
safely proceed to the KLIB serialization stage, at which point we
can show the user a diagnostic about clashing signatures.
Since we've disabled SymbolTable, we also needed to fix the logic that
relied on its presence. Fortunately, such logic only includes
filtering out unused libraries. Instead of iterating over symbols in
SymbolTable, we iterate over cached symbols in Fir2IrDeclarationStorage
and Fir2IrClassifierStorage, which seems to do the trick just as well.
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
Because of KT-64743 there is unexpanded type-alias in a place we don't
expect it to occur. To workaround this, we just expand typialiases in
one more place.
^KT-64743
Normally, 'bindSession()' is called on a 'FirModuleData' right after its
instantiation to make it fully initialized. For source sessions,
this is done directly during the session creation. However, module data
created for dependencies (see 'LLFirModuleData.dependencies' & friends)
stay uninitialized, breaking 'collectAllDependentSourceSessionsTo()'.
To call retrieveDirectOverriddenOf,
one must use directly the owner scope of a callable symbol we consider,
and not a scope of some derived class.
#KT-64276 Fixed
Make sure SENSELESS_COMPARISON
is absent in this case.
^KT-64089 Obsolete
Merge-request: KT-MR-13754
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
Denis.Zharkov