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
`x?.y != null` does not imply that `x != null` if e.g. an argument to
`y` has reassigned `x` in the meantime.
The same is true for `x == y` and `functionWithContract(x, y)`, but
those are somewhat harder to implement since there is no easy way to
find the last node of a certain argument.
^KT-55096
In theory, forking persistent flows should be cheap because of object
reuse, so the proposal here is to start from scratch and prove
redundancy of forks on a case-by-case basis. Something something better
safe than sorry.
^KT-28333 tag fixed-in-k2
^KT-28489 tag fixed-in-k2
val c = C("...")
val d = c
if (c.x == null) return
c.x.length // c.x has type String
d.x.length // d.x -> c.x through d -> c
c = C(null) // remove alias d -> c
d.x.length // info from c.x moved to d.x
^KT-54824 Fixed
- Ensure that typed equals parameter's type is a star projection of
corresponding inline class
- Make possible to declare typed equals that returns 'Nothing'
- Forbid type parameters in typed equals operator declaration
^KT-54909 fixed
^KT-54910 fixed
pyos