Consider a function `run2` that has 2 lambda arguments called in place.
We don't know the order in which they're called, so here:
var x: Any? = something
run2(
{ x = null },
{ x as String },
)
// <--
it's not correct to simply `&&` the statements together, as that would
produce `x is Nothing? && x is String && x is Any?`. Instead, statements
should be grouped by assignment first, and different groups are `||`-ed.
This means in the above example we now get `x is Nothing? || (x is Any?
&& x is String)` == `x is String?`.
For example:
foo(
// `if` joins A & B
if (condition)
run { ... } // A
else
run { ... }, // B
run { ... } // C
) // `foo` unifies `A & B` and `C`, so if it is not resolved itself,
// further `if`s, `when`s, safe calls outside it, etc. continue
// building the correct type predicate until the next completed
// call.
^KT-44512 Fixed
If we want to analyse some function's call, we need to know about its
contracts, otherwise resolving the following code would be broken.
Computing return type of function is a prerequisite to using it in any
sensible way, so it's the best place to resolve it to CONTRACTS
KT-50733
class JavaSuperClass {
// members impls with special signature, but it doesn't override any Kotlin specials
}
class KotlinInterface {
// special members
}
class JavaSubClass extends JavaSuperClass implements KotlinInterface {
// we should obtain members from JavaSuperClass with their Kotlinish
// signature, not the Java one
}
That issue might be fixed via changing
TypeVariableMarker.shouldBeFlexible at ConeConstraintSystemUtilContext
but this and some other tricks have been added because of incorrect
handling of constraints where type variable has a flexible bound
^KT-51168 Fixed
Symbols might be from other modules, so we need to use corresponding
`FirSession`s; otherwise it would be impossible to query symbols
from `firProvider`
^KTIJ-21714 Fixed
If the session is from the other module, it might not know about
FirFiles which are relevant for transforming and resolving the
declaration
^KT-52136 Fixed
In qualified expression like `foo().`, selector expression is null.
Because of that the whole expression was marked as an error FIR
expression, and `foo()` part was not resolved at all (including
arguments and everything else).
This commit fixes the problem by providing receiver's FIR expression
as an underlying expression for error FIR expression. That way
it will be seen by all resolve transformers and will be successfully
resolved.
^KTIJ-21484 Fixed
* Change 1.6 to 1.7 constants
* Fix SAFE_CALL_WILL_CHANGE_NULLABILITY for testData
* Change EXPOSED_PROPERTY_TYPE_IN_CONSTRUCTOR_WARNING to EXPOSED_PROPERTY_TYPE_IN_CONSTRUCTOR_ERROR
* Change NON_EXHAUSTIVE_WHEN_STATEMENT to NO_ELSE_IN_WHEN
* Fix testData for SafeCallsAreAlwaysNullable
* Change T -> T & Any in test dumps
* Change INVALID_CHARACTERS_NATIVE_WARNING -> INVALID_CHARACTERS_NATIVE_ERROR
* TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM_WARNING -> TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM_ERROR
Previously (few commits earlier), it contained two versions
of receiver (lhs) generated separately for each desugaring version
that looked a bit redundant.
Now, at FIR building stage we just don't create desugaring sub-trees,
instead they are being built during bodies transformation and that seems
to be much convenient there, since we don't need to reverse-engineer
get-set-operator version to check if containing calls are successful
(as we just built those calls and retain them)
Semantically, this changes may only change how data flow works
for such statements (see changed compatibilityResolveWithVarargAndOperatorCall.kt)
^KT-50861 Relates
This big refactoring is needed to cleanup building of overrides
mappings and prevent creating redundant intersection overrides in
cases when there is no need in them:
```kotlin
interface A {
fun foo()
}
interface B {
fun foo()
}
interface C : A, B {
override fun foo()
}
```
Before this refactoring there was next override tree:
C.foo
intersection override (A.foo, B.foo)
A.foo
B.foo
Also this commit fixes special mapping of overrides in jvm scopes
for declarations which have kotlin builtins in supertypes with
special java mapping rules (collections, for example)
When stdlib is represented as a source dependency (which seems to be the
case in the `kotlin` project), it will be resolved lazily for the IDE.
Same thing can happen if someone decides to "extend" the stdlib
by declaring their declaration in the `kotlin` package
In both of those cases, we need to make sure that receiver type is fully
resolved before trying to get a `coneType` from it
N.B. To make resolve tests work, I've added a separate folder
`withAllowedKotlinPackage` to the `testData`, because in the default
test setup it is not allowed to extend the `kotlin` package by user's
definitions
^KT-50728 Fixed
When lazy resolve is involved, type bounds can be in an unresolved
state (e.g. `FirUserTypeRef` instead of `FirResolvedTypeRef`). To
enforce the resolve, we use `resolvedTypeBounds` where it might be
important
^KTIJ-20618 Fixed
There just should be a different facades for cases
A<T1, T2> and foo<T1, T2>()
Test data has changed for type alias constructors since previously,
it was working by mistake because of assumption that type alias arguments
are linearly mapped to the type parameters of the corresponding constructors
^KT-50703 Open
Jinseong Jeon