Previously, containingDeclarationSymbol for V was set to the outer class
BaseRoot, so its upper bounds was computed to the ones from TNested
at org.jetbrains.kotlin.fir.resolve.calls.CreateFreshTypeVariableSubstitutorStageKt.getTypeParameterFromExpandedClass
^KT-56706 Fixed
This flag is true by default but is set to false for
- Java methods and constructors
- interface delegation methods that delegate to Java
The NAMED_ARGUMENTS_NOT_ALLOWED logic is mostly refactored to use the
new flag though some custom logic remains for determining the correct
message and to work around a corner case with fake overrides.
The flag is (de)serialized from/to metadata. For backward compatibility
with K1, delegated methods to Java types are deserialized as stable.
^KT-40480 Fixed
FunctionalTypeKind can be used in FE 1.0 too, so there is no need to
keep both classes. Also, removal of FunctionClassKind simplifies work
with FunctionalTypeKind in common code, like Analysis Api
This is needed because now set of available synthetic functional interfaces
depends on session, because each module can contain different plugins,
which provide different kinds of functional types
This is needed to provide an ability to extend different kinds of
functional types
Also, cleanup and rename utilities related to functional types to avoid
possible confusions
The main idea is pre-computing the sets of names that might be
met there, that helps to decrease the sizes of the backing maps
(by avoiding irrelevant keys)
Totally, this branch with previous commits speeds up MT Full Kotlin
approximately on 3 seconds (~5%)
Avoid filling caches with keys that are definitely empty
(if it's cheap to compute that), to decrease the size of backing maps.
The strategy is pre-computing the sets of names that might be met.
NB: the size of the sets is way fewer than a size of all queried names.
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).
Denis.Zharkov