#KT-36247 fixed
A lot of testdata changed because significanly less (error) descriptors
are created for unresolved types, so diagnostics became different.
If the delegated property operators involved are inline, and delegated
property metadata parameter is not used (which is often the case, e.g.,
'lazy'), we can skip those properties in metadata generation.
NOT implemented: special case when only 'kProperty.name' is used by the
corresponding delegated property operators.
Also a sneak fix for KT-34060.
Split error reporting into two parts for incorrect and missing candidates.
Missing function error is not reported on provideDelegate.
Update error factory and default message for error.
Update error texts in quick fix test data.
#KT-16526 Fixed
Expression will be checked against expected type later.
Theoretically, this is not very good, but it aligns with the old
inference, plus it helps avoiding multiple type mismatch diagnostics.
Since we skipped trivial constraint with `Any?` from parameter type of
function `equals`, the compiler thought that there is no proper
constraints (upper bounds do not matter here) and marked resolved
call as a failed one, then diagnostic about missing equals was added
Also, tune `TrivialConstraintTypeInferenceOracle` for `Any?`-like
constraints
#KT-30724 Fixed
The problem is that delegated properties resolve two calls together:
`getValue`/`setValue` with a common receiver, which can contain
callable references. For each completion new anonymous descriptor
was created and caused "rewrite at slice" exceptions later.
Now there is a little hack to check that during one inference session
we don't complete one call more than one time.
More correct fix would be to explicitly specify common receiver for
inference session but it requires quite big refactoring, which will
be done later with a whole refactoring of the common solver
#KT-30250 Fixed
During subtyping/incorporation we transform types (e.g. changing nullability,
form of the type) and, basically, we're doing this to some FIXPOINT.
It's important that we use `KotlinType.hashCode()` to compare types, but
for error types hashCode is a hashCode of its supertype and, for example,
`makeNullableAsSpecified` method recreate type every time. So, we continue
to generate new constraints and we'll never stop incorporation algorithm
Do not call `isError()` on property's type right after creation of
PropertyGetterDescriptor because the property has no getter yet (it's created
but not yet stored to the property, that happens a bit later), and `isError()`
leads to computation of the delegate type, which for delegated properties
performs some complex resolution (see `VariableTypeResolver#process`) which
relies on the fact that the property already has a getter.
Since the purpose of the original change (883e2e4d) was to support a quick fix
which would add the type to a property in an expression like "val x get() =
...", check the type (or initializer) presence in the PSI instead, this is
safer and is still suitable for the quick fix.
Also fix arguments to "wrong getter type" diagnostic: previously something
useless like "expected Int, actual Int" was reported
#KT-11809 Fixed
Mikhail Zarechenskiy