Helps fixing to more specific type in the following situations:
Type1 <: Var1
Var2 <: Var1
Var2 <: Type2
Type1 and Type2 may also be nullable and non-nullable versions of the same type.
Note that no additional constraints can be inferred from such constraints before fixation.
Resulting types for variables will always Type1 and Type2 may also be nullable and non-nullable versions of the same type.
Fixing Var1 first will make Var2's type more specific while fixing Var2 first
will make Var1's type less specific. The first is preferrable in general.
The "free" in "createFreeFakeLambdaDescriptor" and such refers to the
fact that there are no references to type parameters from outside the
current declaration. This is necessary because at the point where the
metadata is written, the type parameters may not even be in scope (e.g.
local delegated properties are serialized at class level, but may refer
to function-scope type parameters).
This fixes smart step into for delegated member functions.
Additionally, we align on the string "memberFunctionName(...)"
for expression non-null checks for both JVM_IR and JVM
backends.
type of the property.
Check for serializer type mismatch only when custom serializer is present
Otherwise, there are too many false positives on e.g. PolymorphicSerializer
#KT-36329 Fixed
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/830
Do not suggest to remove type for public declarations
#KT-38915 Fixed
Do not show intention to specify type when corresponding quickfix is available
#KT-39026 Fixed
This lessens the possibility that kotlin plugin will get different
variants of builtins in the classpath, thus making builtins resources
loading less order-dependent.
Because IrPluginContextImpl constructor creates new instance of
BuiltinSymbolsBase (with symbols for stdlib declarations like `arrayOf` etc),
there should be at least one pass of `declareUnboundSymbolsAsDependencies`
between creation and usage in plugin. Such pass is located between psi2ir
and compiler plugins application. If plugin context is created inside lambda,
right before plugins are applied, the symbols will remain unbound.
#KT-41764 Fixed
Pavel Kirpichenkov