^KT-62027 Fixed
`getCallablesCompatibility` requires parentSubstitutor as a parameter,
but we created a member-level substitutor
`getCallablesCompatibility` will create member-level substitutor itself,
no need to create member-level substitutor on the call site.
IndexOutOfBounds was happening in an attempt of creating member-level
substitutor
I will refactor the `createExpectActualTypeParameterSubstitutor` API in
the following commits later. It will help to avoid problems like that
This is needed because in order to figure out which declarations are
visible from anonymous objects in terms of overridability (see
`FirVisibilityChecker.isVisibleForOverriding`), we need to get the
package name of that anonymous object, because there's package-private
visibility on JVM.
#KT-62017 Fixed
For an example of an object with
an implicit primary constructor,
see `FirPsiOldFrontendDiagnosticsTestGenerated.testSingletonAndFunctionSameName`.
^KT-62005 Fixed
Merge-request: KT-MR-12242
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
Comment was added to make it clear why whole declarations reported
in diagnostic instead of value parameter symbols (same will be done
with other targets in subsequent commits).
^KT-60671
It is incorrect because has expect and actual in same module,
which results in ACTUAL_WITHOUT_EXPECT reported in FIR.
But there is already same test
`multiplatform/incDecOperatorsInExpectClass.kt`, so there is no need
to fix and maintain test `IncDecOperatorsInExpectClass`.
^KT-60075 Fixed
This fixes a false positive OVERRIDING_FINAL_MEMBER caused by a
package-private member in a different package being added to the
list of overridden symbols. However, in Java, package-private members
from different packages are effectively like private members in that
they cannot be overridden.
#KT-61696 Fixed
For members of nested classes inside expect class
`classWrapper.hasExpect()` would be false, because it only reflects
modifiers of nested class itself and not aware of "expect" modifier
inherited from the parent class.
Fix is done in same way in PSI2FIR, see
`PsiRawFirBuilder.Visitor.toFirProperty`.
This fix now makes it possible to add test for functionality from
previous commit.
Review: KT-MR-12107
^KT-61784
...not reporting on companion object members as well as other
nested classes.
Annotation classes are accepted because this is how it already worked,
see other tests, for example `annotationsViaActualTypeAlias.kt`.
Test for nested annotation classes will be added in subsequent commit,
because it currently will fail in test
`TreeCompareTest.testCompareDiagnostics` because light-tree2fir
produces different tree due to a bug when converting properties
from expect primary constructor. See subsequent commit for a fix.
Review: KT-MR-12107
^KT-61784
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
The original Java checker has an early return in
case of `resultingDescriptor !is JavaClassConstructorDescriptor`.
It fires if the descriptor is
`TypeAliasConstructorDescriptor`, thus further
diagnostics are not reported.
Adding these dependencies to the `api` configuration pollutes classpath for each dependant modules even if it doesn't need them. Instead, the dependencies should be declared more granularly if they're required
#KTI-1349 In Progress
The `kotlin-test` dependencies are left untouched as changing them affects publications, thus these versions are independent from the used inside our build
#KTI-1349 In Progress
There is a corresponding example inside the stdlib,
see `kotlin.text.startsWith`.
JVM and common counterpart are weakly-compatible
as the actual declaration has default arguments,
which results in `ExpectActualCompatibility.Incompatible.ActualFunctionWithDefaultParameters`
This commit allows such cases.
^KT-61732 fixed
IllegalArgumentException: class
org.jetbrains.kotlin.psi.KtLambdaArgument is not a subtype of class
org.jetbrains.kotlin.psi.KtExpression for factory
TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM
was reported when TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM was
reported on a FirLambdaArgumentExpression, report it on its
`expression` instead.
#KT-60380 Fixed
There was only one real inheritor of AbstractFirBaseDiagnosticTest,
so there is no need in the whole hierarchy of abstract test runners
Also AbstractFirOldFrontendLightClassesTest is not intended to check any
diagnostics or CFG dumps, so this logic was removed (they still can be
checked using non-legacy AbstractFirDiagnosticTest from the main test
infrastructure)
UncaughtExceptionPath edges are used to influence smart-casting within
catch and finally blocks. Previously these edges were added from every
node which could throw an exception. But only assignment nodes influence
smart-casts by resetting inference back to some less specific type.
Therefore, instead of tracking every possible node which could throw an
exception - even though almost every statement node can - only add edges
from assignment nodes to catch and finally blocks. This fixes many
missing exception cases and also reduces the total number of incoming
edges to catch and finally blocks.
#KT-56872 Fixed
Ivan Kochurkin