^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?`.
If a variable does not yet exist, then it should only be created if it
is a real variable and the implication or statement we're about to add
is about its type or nullability (which is also about the type).
Otherwise, the statement/implication will have no effect because there
are currently no implications referencing that variable, and if it's
synthetic then there will never be because we won't visit it again.
Hopefully this reduces the performance impact of flow forks.
This also fixes some returnsNotNull contracts because the old code added
an implication that `== true` => `!= null` then promptly removed any
statement that this could've affected if the argument was a synthetic
variable.
^KT-26612 tag fixed-in-k2
Dmitriy Novozhilov