^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
When checking top-level properties, check with initialization enabled.
This makes sure the same errors are reported for member and top-level
properties.
...without `isTopLevelOrInsideClass` property. Behavior stays the same,
because in fact we require all `expect` member declarations to be non-private
except constructors and property setter.
Enhance already existing test.
^KT-59899
We don't want any `expect` function to have body. So we're sure no
new false-positive reports are introduced because of removal of
`isTopLevelOrInsideClass` condition.
^KT-59899 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
In this commit we begin counting a catch parameter as
both a local variable and a value parameter for the purpose
of annotation targeting.
#KT-61691 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
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.
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
@ImplicitlyActualizedByJvmDeclaration is the only one
OptionalExpectation annotation which works correctly when set only on
`expect`. All other (like @JvmName, @JsName) - not, so warning for them
must be reported.
^KT-61725 Fixed
Nikita Bobko