ensure fir annotations are included in FirDanglingModifierList and resolved,
dedicated DanglingTopLevelModifierListStructureElement exists for top
level lists only, class level lists are processed by containing structure
element
This feature is not needed because it is unconditionally disabled for K1
(because of not fully correct implementation) and unconditionally enabled
in K2 (K2 does not support old behavior)
^KT-38895
Incompatible supertypes check also don't provoke runtime problems
in most situations, because this check is also bound to type argument
conflict. Related to KT-54411
The situations with conflicting type arguments normally don't provoke
any runtime problems. Also, conflicts like A<T> VS A<SomeType> aren't
valid at all. Here we decided to remove them to avoid strange
and non-actionable warnings in user code.
#KT-54411 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
If a certain type statement is true on loop entry and all continue
paths, then it is also true on exit if the condition did not reassign
the variable.
^KT-7676 tag fixed-in-k2
It's also not a backwards jump in do-while, unless it's in the loop's
condition, which is a stupid "feature" IMO. As you can probably tell
from the comments added in this commit.
- Add a checker which ensures that property accesses have no explicit
type arguments. If an error on the property access's callee reference
already exists, the new error is not reported in favor of the existing
error, as the property access may have been intended to be a function
call.
- `complicatedLTGT.fir.kt`: The underlying parser issue is not yet
solved, which is why `x` is parsed as a property access with explicit
type arguments.
- `reservedExpressionSyntax` tests: This new check makes a lot of the
access expressions in these tests illegal, so valid lines have been
added and invalid lines appropriately marked with
`EXPLICIT_TYPE_ARGUMENTS_IN_PROPERTY_ACCESS` errors.
^KT-54978 fixed
- Allow 'lateinit' for inline classes which underlying type
is suitable for 'lateinit'
- K2: report all problems related to 'lateinit' modifier
^KT-55052: Fixed
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
Otherwise, OVERLOAD_RESOLUTION_AMBIGUITY is reported for the calls to
the functions annotated as @OverloadResolutionByLambdaReturnType
^KT-43296 In Progress
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
Also remove incorrect subtype check checkers
Test unsafeVarianceInAliasedFunctionalType.kt started to fail because
of KT-54894. This bug existed before, changes from this commit just
unhided it (previously it was hidden because incorrect subtype check
in `isSubtypeForTypeMismatch` which is used by FirFunctionReturnTypeMismatchChecker
Anna Kozlova