`T.() -> R` and `(T) -> R` should only be
different for resolution, but casts are only
about typechecking. Values of either of
these types can always be put into variables
of the other type.
This way it's easier to reason about where
useless casts/is checks come from, because
everything is on the same screen.
`USELESS_CAST` disappeared from
`FirPsiJsOldFrontendDiagnosticsTestGenerated.testDynamicCastTarget`
because
`LanguageFeature.EnableDfaWarningsInK2`
is disabled, and previously it only
affected `FirCastOperatorsChecker`, but
not `FirUselessTypeOperationCallChecker`,
which felt like an unintended mistake.
A related issue: KT-50965
This makes it more consistent and fixes some
overlooked corner cases. Also it was decided
on the last equality applicability DM
(KT-62646) that we'd like
`is`/`!is`/`as`/`as?` to work similarly
to `===`/`!==`.
Also note that it now gives a clearer
explaination of why some corner cases work
the way they do. For example,
`FirPsiDiagnosticTestGenerated.testLambdaInLhsOfTypeOperatorCall`
yields `UNCHECKED_CAST` instead of
`CAST_NEVER_SUCCEEDS`, because
`toTypeInfo()` replaces all type arguments
with star projections, even when the argument
is not a type parameter. This is because
it has been desided to work this way in
KT-57779.
In
`FirPsiOldFrontendDiagnosticsTestGenerated..NeverSucceeds#testNoGenericsRelated`
the diagnostic is introduced, because
`t2 as FC1` and `FC1` is a final class with
no `T5` supertype.
`UNCHECKED_CAST` in
`FirPsiOldFrontendDiagnosticsTestGenerated.testSmartCast`
disappeared, because previously we didn't
take smartcasts into account.
Note that
`FirPsiOldFrontendDiagnosticsTestGenerated.testMappedSubtypes`
is a false positive. It appears because `isSubtypeOf()` doesn't
take into account platform types in supertypes of the given types
(doesn't map them).
Most probably it was there just to guarantee
that if `argument` is not a smartcast
expression then this property is exactly the
same thing as `originalType`, but it seems
there's not much point in that as none of
the tests fail.
`lowerThanBound()` was renamed to:
- draw attention to its corner cases
- make its single usage less cryptic
We may want to reserve the pretty name for
a function that, for example, returns `true`
if `argument` suits all the bounds.
Similarly, `canHaveSubtypes()`
does some questionable logic in case of
`INVARIANTxINVARIANT`: some hypothetical
`Inv<Foo>` doesn't have subtypes so
checking "Foo has subtypes strictly above
Nothing || Foo has supertypes strictly below
the parameter bounds" doesn't seem correct.
`Foo` may have some, but `Inv<them>` are
not related to `Inv<Foo>`.
It was decided to forbid such comparisons,
as we know how `===` works. Also, added some more
test cases, just for comparison.
Reusing the proper `canHaveSubtypes()`
from `TypeUtils` prevents a breaking change
in:
- `comparingTripleWithPair.kt`
- `comparisonOfGenericInterfaceWithGenericClass.kt`
But it does lead to warnings
(instead of errors) in
`incompatibleEnumEntryClasses.kt`, which is an
unrelated mistake that will be fixed in the next
commit.
The refactoring in `canHaveSubtypes()` is purely
cosmetic - otherwise reading these conditions is hard
(and they don't fit my screen vertically).
^KT-62646
^KT-65541
^KT-57779
`@Suppress` annotation has `VALUE_PARAMETER` target, so when a property
in the primary constructor is annotated with `@Suppress` it sticks
to the parameter. But the suppression should work for all diagnostics
reported on the parameter **and** the property
^KT-66258 Fixed
This extension point allows changing the return type of call
from a declared type to its subtype.
With an idea that such a plugin needs the ability to
control available (extension) properties for this type.
A set of properties should be decided based on the resolved function,
provided arguments, types, and resolved lambdas.
It is not a goal to enable plugins to affect resolution in any way.
Types are not intended to have any structured capabilities
In other words.
The goal was to come up with a way to enable a limited form
of an "extensible records" mechanism through plugins.
- It should give enough value for a practical use.
(more info in the ticket).
- It should have minimal effect on the compilation process
This appears to be an extension point that solves this problem.
^KT-65859 Fixed
When collecting local properties for property initialization analysis,
the nodes of the CFG were navigated. However, there are problems when
trying to determine what local properties are defined within do-while
loops. This is because the node order of a CFG does not always follow
the FIR structure order.
By converting the collector to a FIR visitor, we can maintain the
structural order needed for finding properties defined within do-while
loops. This does require some additional logic though to make sure we
do not navigate into elements which are not part of the original graph
navigation.
^KT-65911 Fixed
Checker for conflicting declarations will now check for the following
scenarios too
- two expect declarations in different modules
- actual and non-expect declarations in different modules
^KT-63826 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`.
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
When a declaration with an ObjC annotation is stored in a different
module, the annotation arguments are not resolved by default. This leads
to a bug in the checker. Before attempting to find the objCName, it is
necessary to resolve the annotation first.
#KT-64276
There's been a change in the error message for
INCOMPATIBLE_OBJC_NAME_OVERRIDE in K2 which makes it much more difficult
to diagnose the underlying issue. Previously in K1 the symbol that had
an incompatible objc name would be output, but in K2 only the class
declaration is output making it difficult to determine which member is
causing the error.
#KT-65572 Fixed
`testIntersectionOfPrimitiveBasedFunctions`
is fine, because we deprecate this
already in ^KT-63243.
`CANNOT_INFER_VISIBILITY` is
positioned as `DECLARATION_NAME`,
just in case we decide for
some reason that we do want to
report it along with
`MANY_*_NOT_IMPLEMENTED`. In that
case, we'd get a problem that
their bounds overlap, but not
completely contain one another.
^KT-63741 Fixed
^KT-59400 Fixed
Even though SO may not be correct
overrides sometimes, it feels more
natural to treat fake overrides as...
well, "overrides". And without it
we'd need to make the code in
`FirOverrideChecker` less intuitive.
The change in
`FirOptInUsageBaseChecker` is needed
to prevent `OPT_IN_OVERRIDE` on
intersection overrides where one
of the base functions requires opt-in.
We never designed this in such
a way that it's an error.
See:
`FirPsiOldFrontendDiagnosticsTestGenerated.testIncorrectTargetsForExperimentalAnnotation`.
According to KT-63741, the case like
`kt40510.fir.kt` should, in fact,
be an error. It will be addressed
separately.
In general, overrides should not
contain default values, and it's
better to make fake overrides be close
to proper overrides as much as
possible. It will be important when
we begin running `FirOverrideChecker`
for fake overrides.
^KT-63879 Fixed
^KT-65534
Nikolay Lunyak