In init block or property initializers,
for `val x` declared in primary constructor,
`x` reference is now resolved to property, not to parameter.
So we need two different scopes for primary constructor,
one for 'pure' parameters and another one for all parameters,
including val/var ones.
#KT-42844 Fixed
There is introduced algorithm of resolution with jumps: before
resolution of some class we resolve all status of members of its
supertypes, so we can properly determine inherited visibility
and modifiers
This commit introduces several different things, in particular:
- check type arguments in expressions
- new TypeArgumentList node to deal with diagnostic source
- ConeDiagnostic was moved to fir:cones
- ConeIntermediateDiagnostic to use in inference (?) without reporting
- detailed diagnostics on error type
Before this commit, we had effective visibility as a part of FIR status,
so it was integrated into the full pipeline. In this commit,
we introduced "effective visibility as a service" which is now used
only by exposed visibility checker. This allows us to make the thing
universal for all FIR nodes, including nodes for Java / deserialized.
Before that commit we desugared `a ?: b` as
when (val elvis = a) {
null -> b
else -> elvis
}
It was incorrect, because `a` should be resolved in dependent mode,
but when it was `elvis` initializer it was resolved in independent
mode, so we can't infer type for `a` in some complex cases
Mikhail Glukhikh