- If class has type arguments (A<T1,..>) then
resolve it's delegation call to `this` as for expression A<T1, ..>()
like type arguments are explicitly specified.
- Same logic works for `super` delegation calls.
- It could be just enough to substitute all candidates before resolve
but diagnostic messages looks more correct when substitution is
performed within CandidateResolver.performResolutionForCandidateCall
because it works the same way as when resolving A<T1, ..>().
#KT-6992 Fixed
#KT-6993 Fixed
#KT-6994 Fixed
This check is obsolete but leads to problems.
It appears when resolving recursive calls (see sameTypeParameterUse.kt):
`foo<R>(x: R, y: R)` within call `foo<R>(x, "")` after substitution
has R as type of it's second argument, and when checking value arguments,
x is not checked because supposed to be dependent on type parameter of candidate
(that is effectively false), so there are two successful candidates
in resolution results and wrong OVERLOAD_RESOLUTION_AMBIGUITY error.
Previously we prohibited classes and properties with the same name (now it's unnecessary)
Add test for backends that they support qualified (by default object name) member references inside class body
Star-projections have upper bounds of the form "parameter's bound where all parameter of the same class are substituted with their star-projections"
#KT-6803 Fixed
- It's worked almost fine but diagnostics were filtered out by
positioning strategy.
- Also a couple of "put" calls to Multimap are replaced by "putValues"
within OverloadResolver, that is more semantically correct.
- Note that constructors of top-level classes are handled when processing
package, it helps to figure out if there are clashes with top-level
functions that have the same name.
- But constructors of different classes are not reported as
overloads because containing classes has the same name and will be
reported as redeclaration.
When deal with constructed object (not this) treat it like it's fully initialized.
Otherwise (this or access with no receiver) access instruction
should be handled as it was before.
#KT-6788 Fixed
#KT-4126 Fixed
Alexey Tsvetkov