Many errors are reported in stdlib with these annotations
(SinceKotlin, Deprecated, so on).
But having them only on expect is a valid case. E.g. SinceKotlin added
if some old platform-specific API becomes commonized.
^KT-58551
This implementation only checks annotations set on expect/actual
declarations and requires further refinement (e.g. checking of other
annotation targets, class scopes within typealiases).
^KT-58551
This commit is a follow-up to 0d070f8ba9.
Here we remove accidentally returning "Not a sub-type" for a constraint
like TypeVariable <: DNN type
#KT-59241 Fixed
In terms of MPP there are no such thing as `expect constructor` for enums,
but they are physically exist in FIR and IR, so we need a switch which
skips matching for them
FE 1.0 implementation did not touch to avoid any hidden changes
Also use TypeSystemContext instead of TypeSystemInferenceExtensionContext
in AbstractExpectActualCompatibilityChecker
This is needed to have an ability to implement ExpectActualMatchingContext
for IR backend. IrTypeSystemContext may operate with type substitutors,
but there is no sense to implement all methods from TypeSystemInferenceExtensionContext
in it
Previously, it was led to plainly adding NullableType <: T constraint
which silently led to successful call completion.
What is suggested is just marking such initial constraint
as unsuccessful.
In K1, the error was reported just via additional type checking
mechanism being run after call completion.
^KT-58665 Fixed
There's a heuristic for approximation of a captured type that once
it has non-trivial lower bound (other than Nothing), it's worth
approximating it to sub-type even while the containing
top-level type is being approximated to super-type.
And that sounds reasonable in case the lower bound is indeed non-trivial,
but that's not the case because nullability here comes from
the nullability of captured type position.
So, the fix is basically not to treat such approximations as non-trivial.
And while that seems to be a bit of a change in the language semantics,
it still looks reasonable (see other changes in test data and KT-58087)
^KT-57958 Fixed
^KT-58087 Fixed
This fixes a FIR-specific issue where a type variable is inferred to
Any instead of dynamic. K1 wasn't affected because of a FIR-specific
condition in ResultTypeResolver.
#KT-57962 Fixed
See the comments in the code, but mostly the motivation is that once
it was decided to stick with such a legacy thing as raw types,
we are ok with some corner-cases hacks for them
(if there are not too many of them) and they don't break anything
when there are no raw types in the code.
^KT-56616 Fixed
Namely, do not choose `Nothing?` result type when fixing a variable
that has other constraints besides the ones that came from
the relevant type parameter's upper bounds.
See more details in KT-55691.
In K1, the case from specialCallWithMaterializeAndExpectedType.kt
was working (inferred to String?) just because the branches
were analyzed independently with `String?` expected type.
This change became necessary after the previous commit when we united
inference subsystems for if/when branches (see motivation there).
NB: For K1, the behavior is left the same, but the code
was refactored a bit.
^KT-55691 Fixed
^KT-56448 Fixed
When constraint system has forks in it usually we solve all of them before
starting full completion of corresponding call. But if some call with
forks was a last statement of postponed lambda, we will never call
completion for it with FULL mode. Instead of it we complete it in PARTIAL
mode and then just merge its constraint storage into storage of outer
call. So all forks from this inner call just remain unresolved inside
outer system without this fix
^KT-55966 Fixed
Callable symbols with SinceKotlin are filtered out by a
resolution stage, but in K1 classifiers and property accessors
report API_NOT_AVAILABLE. K2 filters out properties with
unavailable accessors, but does nothing for classifiers.
This change fixes it.
^KT-54410 Fixed
In K1 analogue of `K2_VISIBILITY_ERROR` is `K1_RUNTIME_ERROR`, so
candidates with `K2_VISIBILITY_ERROR` should win over innaplicable
candidates with `INAPPLICABLE`, `INAPPLICABLE_ARGUMENTS_MAPPING_ERROR`
or `INAPPLICABLE_WRONG_RECEIVER` applicability
This is needed to allow resolution to invisible symbols (and later
suppress error with `@Suppress("INVISIBLE_SYMBOL", "INVISIBLE_REFERENCE")`
^KT-55026 Fixed
^KT-55234
Otherwise, exception from org.jetbrains.kotlin.resolve.calls.inference.components.ConstraintInjector.TypeCheckerStateForConstraintInjector.fixedTypeVariable
might happen during forks resolution
The test data is extracted from intelliJ FP test
^KT-43296 Fixed
The idea is that we should not fix (i.e. choose any of the fork branches)
on the stage of candidate processing before completion, but it's enough
just to check that current state can be converged to success.
And when completion starts, and we add expected type to the system,
we've got more information to choose the correct fork branch.
NB: The old `processForkConstraints` is being called just
at the beginning of the completion phase.
^KT-43296 In Progress
Roman Efremov