Consider following case:
fun foo(): Unit = run { "hello" }
Previously, NI would analyze lambda body without expected type, because
it is a type variable 'R' from 'run', which hasn't been fixed yet. This
leads to treating "hello" as lambda-return argument and adding bogus
'String' constraint on 'R', and, consequently, type mismatch.
Now, we peek into current constraint system and check if return-type of
lambda is type variable with upper-Unit constraint (which is exactly
condition for its body to be Unit-coerced). If so, then we provide
expected Unit-type for body explicitly, and the rest will be done
automatically (in particular, in aforementioned example "hello" wouldn't
be treated as lambda return argument).
Only store the ClassId of the enum class and the Name of the entry, and
resolve the needed descriptor in getType() instead, which now takes the
module instance where that descriptor should be resolved
Using the argument value, which is of type "Any?", is more implicit and
thus difficult to read than using the ConstantValue instance and casting
it to the needed constant value implementation before taking the value
Only require implementations to be able to compute the enum class name
and the corresponding entry name. Only this should be necessary to
correctly resolve the argument; the resolvers will find the
corresponding class descriptor if necessary
Remove KotlinBuiltIns and take a ModuleDescriptor instance in getType
instead. This will allow to create constant values in contexts where
there's no module or built-ins accessible (such as, deserialization of
module annotations during indexing of .kotlin_module files in IDE).
Note that some values (KClassValue, EnumValue, AnnotationValue) still
take module-dependent objects (KotlinType, ClassDescriptor and
AnnotationDescriptor respectively). This is to be refactored later
At the only call site of getDefaultArgument it is checked that the
parameter actually _declares_ default value, so it's not necessary to
try to load that value from supertypes