During converting library annotations to FIR nodes
and building required scopes inside, lazyResolveToPhase may be called.
For such cases it's okay to skip the lazy resolve contract checks as
those declarations are always fully resolved and
lazy resolve will do nothing.
It's anyway safe to use avoidComprehensiveCheck = true because
during deserialization we're sure that we need DNN type because
it's been serialized as such.
I.e. if T is already bounded by Any, deserialize T&Any as simply T
(instead of producing either an error type or an NPE, the latter
happening when the T&Any is the lower bound of a flexible type somehow)
Once again this is a problem of the kind where some weird combination of
FE1.0 and FIR causes a weird edge case error on invalid input and creating
a test with that specific setup is not really feasible.
In DeserializedClassDescriptor and MemberDeserializer, only the
`contextReceiverTypeList` field was used, and not
`contextReceiverTypeIdList` which is used when `-Xuse-type-table` is
enabled. The convention is to use a bunch of utilities declared in
`protoTypeTableUtil.kt` which deal with both methods of reading types.
Also, simplify the deserialization code in FIR (which was correct for
some reason).
This is needed for two reasons:
1. Before this change companion object appeared in FirRegularClass
twice: in declarations list and in companionObject field. This may
trigger twice transform of it
2. It's very hard to implement generation of companion object by plugins
because if it is part of the tree then generated declaration must be
registered in FirProvider, which is inconsistent with other generated
declarations. Replacing FIR with symbol and removing custom logic of
visiting/transforming companion FIR allows us to just replace companionSymbol
in FirClass if plugin wants to generate it without any additional work
Those modules are:
- :compiler:fir:providers, which contains Fir and Symbol providers,
scopes, and different utilities used by them
- :compiler:fir:semantics, which contains different abstractions and
entities which are used in resolution and in checkers
- :compiler:fir:resolve, which contains all stuff related to resolution
and inference
There are two pros of this change:
1. It may increase gradle build, because it allows to compile :fir:resolve
and :fir:checkers modules in parallel
2. Logic of working FIR (scopes, providers, DFA logic system, etc) is
now separated from logic of resolution phases, so for example checkers,
which are depend on scopes physically will not be able to run resolve
in any way
Mikhail Glukhikh