DataFlowValueFactory and its environment refactoring: containing declaration is added into factory functions
as an argument and used to determine identifier stability. A few minor fixes. #KT-5907 Fixed. #KT-4450 Fixed. #KT-4409 Fixed.
New tests for KT-4409, KT-4450, KT-5907 (public and protected value properties used from the same module or not,
open properties, variable properties, delegated properties, properties with non-default getter).
Public val test and KT-362 test changed accordingly.
- Before this change members just left unresolved as they were absent in the
specific scope named scopeForSecondaryConstructorHeaderResolution that
created just to prohibit such accesses.
- Now they are resolved the same way as other members, but diagnostic is
repored by in-place injected CallChecker
- Drop obsolete type of class scope
#KT-6995 Fixed
- Always report "There is no applicable constructor for call without arguments in superclass"
under `constructor` keyword by replacing default TracingStrategy
- Remove positioning strategy used for reporting non-applicable
for empty delegation calls
#KT-6971 Fixed
- 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.
Mikhail Glukhikh