This commit includes:
- introduce FirResolvedDeclarationStatus.effectiveVisibility
- replace FirEffectiveVisibility with EffectiveVisibility
- move calculation of effective visibility from FirEffectiveVisibilityResolver
(which is deleted) to FirStatusResolver and FirDeserializer
This is required for calculating of effective visibility, because it
depends on effective visibility of outer class (those changes are
added in next commit)
Also fix incorrect designation building for local classes
When we check overrides from IDE, we need to check argument types for subtyping.
When checking for subtyping, we need type parameters declared
in defining classes to be resolved to TYPES phase
and super types to be resolved to SUPER_TYPES phase.
Otherwise, they will be resolved to RAW_FIR and subtyping will throw
"ISE Expected FirResolvedTypeRef with ConeKotlinType but was FirUserTypeRefImpl"
Currently VAL_REASSIGNMENT are only reported on direct assignments.
Reassignments in the form of, for example, `+=` are reported as
`VARIABLE_EXPECTED`, which differs from FE1.0.
KotlinTypeMapper.mapInlineClassTypeAsDeclaration and
mapUnderlyingTypeOfInlineClassType invoked mapType which is defined in
descriptorBasedTypeSignatureMapping.kt and works on KotlinType.
It didn't lead to any problems, other than the fact that we were
constructing IrBasedClassDescriptor in JVM IR, and then KotlinType to
pass it to mapType, on each call to StackValue.boxInlineClass or
unboxInlineClass, which seems wasteful.
Instead of this, refactor these utilities to use type markers instead,
pass IrType and IrTypeMapper directly from JVM IR, and move the "static
type mapper" logic (which is used only in the old backend) out of
KotlinTypeMapper.
From now on sealed declarations get resolved with the help of
FirIdeSealedHierarchyProcessor. This change entails correct IDE side
check for sealed when exhaustiveness.
Besides adding VALUE_PARAMETER_WITH_NO_TYPE_ANNOTATION,
we remove here NO_TYPE_FOR_TYPE_PARAMETER since it doesn't exist in FE1.0.
The name also doesn't make much sense.
From the usage it looks like it should have been
VALUE_PARAMETER_WITH_NO_TYPE_ANNOTATION instead.
Mikhail Glukhikh