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
Introduce ExtensionProvider which takes care of caching application using weak reference
Fixes a memory leak for scenarios with application being substituted (Jps build does that when compiling multiple modules)
- 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
- Move resolution logic from BodyResolver to CallResolver
- Call resolveConstructorDelegationCall explicitly without resolveFunctionCall
- Drop dead condition and unused method
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.
Denis Zharkov