When reporting INFERRED_TYPE_VARIABLE_INTO_EMPTY_INTERSECTION, search
for a call to a declaration with the type parameter that got inferred
into an empty intersection inside the expression.
#KT-56377 Fixed
FIR expressions rendered by FirRenderer don't look very nice in error
messages anyway, and additionally, they can become arbitrarily large,
so we shouldn't use them in messages.
#KT-59449 Fixed
When a call is resolved to a classifier, only a single error message was
being used for multiple cases. This lead to confusion as the default
message may not be applicable to a given error case. Added additional
errors and messages to distinguish between these error cases.
#KT-57251 Fixed
Previously the argument type was being used for the actual type error
display. However, safe-call arguments are unwrapped which causes
nullable types to be displayed as non-null. Change to use the actual
type provided by the diagnostic instead of extracting the type from
the argument.
#KT-58844 Fixed
To make sure all possible types are resolved and any additional errors
are reported, resolve children of function calls using independent
resolution mode when the callee reference is an error.
#KT-59041 Fixed
Error message was only printing the calling inline function and not the
class member being accessed. Make sure both pieces for diagnostic
information are included in the error message.
#KT-58972 Fixed
In this commit we have a lot of change in test data. This was caused
by the way where we evaluate constants. We split constant evaluation
into two distinct parts: only necessary evaluations for `fir2ir`
(like const val and annotations) and optimizations for lowering.
Now we don't do all constant evaluation on `fir2ir`, but IR
dump is executed after this phase, so test data changed.
#KT-58923
This commit is a follow-up to 0d070f8ba9.
Here we remove accidentally returning "Not a sub-type" for a constraint
like TypeVariable <: DNN type
#KT-59241 Fixed
See the test data.
ISE happened because at some point after incomplete `getValue` resolution
of `a` property, we updated in the `transformAccessors` the property type
to the `Variable(Y)` type and then used it as a 3rd argument for
`setValue` call which is incorrect because the variable belongs
to a different constraint system (from `getValue`).
Mostly, the fix is just a repeating K1 behavior, namely postponing
`setValue` resolution until delegate inference is completed.
^KT-59066 Fixed
In terms of MPP there are no such thing as `expect constructor` for enums,
but they are physically exist in FIR and IR, so we need a switch which
skips matching for them
FE 1.0 implementation did not touch to avoid any hidden changes
See 2e5b783cc6 for details
After the fix for KT-57694 (mostly rewritten JvmMappedScope),
the behavior of loading new JDK 21 members of K2 has been aligned with K1