The previous one was incorrect for K1 since parent of top-level function
is `IrClass`, not `IrPackageFragment`.
The change is non-functional, K1 still worked correctly, but had to do
some extra work when inlining `emptyArray` calls and produces less
performant bytecode.
It was a workaround for case, where expect class don't have
override of abstract function. We don't allow it anymore,
so it can be dropped to make correct modality comparation.
^KT-65971
This fixes some crashes on red code in diagnostic tests.
Also can be useful in the future, when we would allow things like
enum.name in annotation arguments.
^KT-65971
Otherwise, when analyzing
`PsiTypeParameterListOwner` in the
related test, we (after flattening and
`nonSubsumed()`) get 2 `JvmMember.accept`
from the same very java enhancement
scope `JvmMember`.
^KT-65972
After this change the IO created for
`SimpleColoredComponent::setToolTipText`
will be `containsMultipleNonSubsumed == true`
while IOs created for classes in
`intersectionOverridesIntersection.kt`
will have this property set to `false`.
^KT-65972 Fixed
Allow multiple bases with default
implementations as long as there's a
non-abstract symbol from a class.
Our rules for Kotlin are stricter than
those in Java.
Check all members for `Visibility.Unknown`,
otherwise we miss them when they come
from supertypes. This is the reason why
the FP intellij build failed with a
cryptic stacktrace instead of a
human-readable diagnostic.
Also, do report the diagnostic at all
cases of `Visibilities.Unknown`. Turns
out, there are no "simple to reason
about" situations here :(
Also, an interesting detail:
`retrieveDirectOverriddenOf` returns an
empty list for intersection overrides.
But this doesn't seem to break anything...
Replacing `CANNOT_INFER_VISIBILITY`'s
type `KtDeclaration` with
`PsiNameIdentifierOwner` and the related
changes in `PositioningStrategies`
were needed to prevent an exception saying that
`PsiClassImpl` is not a subtype of
`KtDeclaration`.
This code does lead to inferring
`Visibilities.Unknown`, but it's not
reported anywhere. This is because it
happens inside `AbstractIntSet` which
comes to us "pre-compiled" by javac,
whereas `FirOverrideChecker` only checks
members within `KotlinClass`.
^KT-65972
The rule of thumb is the following:
If the `if` and `when` can be successfully replaced with `while`,
then it is used as a statement, otherwise, it is used as an expression.
#KT-59883
All existing tests use custom test data for FIR because the diagnostic
text in FIR has to have a dot at the end. Also, the K2 checker doesn't
check usages in imports because there are no "import checkers" in K2
right now, this will need to be fixed later if necessary.
#KT-60797 Fixed
Previously @EnhancedNullability for IR type was added if only there wasn't
an @FlexibleNullability annotation, which is inconsistent with K1
behavior
^KT-65302 Fixed
In some cases we transform flexible type into non-flexible during
enhancement, but don't add `@EnhancedNullability` attribute to them,
which breaks consistency with K1 on IR level
This commit fixes it
^KT-65302
Fix some unresolved supertypes. This is necessary to be able to enable
IR fake override builder by default (KT-61514), because it traverses all
supertypes and asserts that they're classes, so that it can build fake
overrides for declarations from there. Without this change, for example
`IrFakeOverrideBuilder.buildFakeOverridesForClass` would crash.
based on the regular compiler tests infrastructure, but adding
directives that can customize the definition from testdata.
So far only default imports and provided properties are supported, but
the infrastructure is easily extendable to other customizations.
Another limitations that provided properties are not supported for
the black box tests - the constructor parameters computing code
should be adapted to support it.
Note: in order to pick up the customized definition, the script files
should have an extension .test.kts
A class can inherit two declarations that are compatible from the
overridability standpoint and are therefore combined to a non-trivial
intersection.
At the same time, the class can declare a member declaration that
only overrides one of the intersection's members.
In this case, we break up the intersection and only add the overridden
parts to the declared member's direct overridden list.
If the class doesn't override the intersection, it exists as
intersection override, like before.
#KT-65487 Fixed
vladislav.grechko