^KTIJ-23421
hide explicit builtins to reveal target platform dependencies.
Otherwise, `expect` class from builtin of e.g. JDK
would be found instead of actual dependency from Kotlin Runtime
AllOpen plugin makes the properties all-open, but the annotation class
is left closed, because allopen for k2 literally checks
`classKind == CLASS`.
Since the properties are open, a
`NON_FINAL_MEMBER_IN_FINAL_CLASS` diagnostic is reported for them. It's
positioning strategy seeks for the explicit `open` modifier which is
not present.
The added test should not crash the compiler.
^KT-54260 Fixed
This is needed not only as optimization, but also for cases, when
inferred type of function may differ from type of single expression.
Such situation may occur after next commit, which adds approximation
of return type of all declarations:
```
interface A
interface B
interface C : A, B
interface D : A, B
class Inv<T>(val x: T, val y: T)
fun foo(c: C, d: D) /* : Inv<Any> */ = Inv(c, d) /*: Inv<A & B> */
// Inv<A & B> /<: Inv<Any>
// but there should be no error
```
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
Thinking of monomorphizing `Flow` (= `PersistentFlow`) and instead
adding a completely separate `MutableFlow` version; then `joinFlow`
would produce a mutable one, data flow analysis would add some
statements, convert to a persistent `Flow` and proceed to the next
node.
The code was already duplicated between FirDataFlowAnalyzer and
FirReturnsImpliesAnalyzer, so might as well use the latter to slightly
speed up the former.
This makes the `returns() implies` checker slightly cleaner, and also
fixes the case that I've missed where in RHS of `x ?:` type of `x` was
not set to `Nothing?`.
Sergey.Shanshin