Annotation loaders for descriptors (AnnotationAndConstantLoaderImpl) and
stubs (AnnotationLoaderForStubBuilderImpl) share the loading logic until
mapping ProtoBuf.Annotations to output values. The shared logic has been
extracted to the base class.
KTIJ-26761
KTIJ-26961
This flag will be used on JVM to determine whether or not to generate
external enum entries mappings ("$EntriesMappings") classes. Note that
from the frontend's point of view, every enum has `entries`, so for
backend purposes we have to reach out to the underlying deserialized
data to read the flag from the metadata.
Otherwise, when adding a typealias to core/builtins, it leads to an
exception "JvmBuiltins instance has not been initialized properly". It
happens because we start computing typealias constructors even before
the compiler has been initialized properly.
Basically we're creating the container, and as a part of it, we're
computing default imports, and for that we need to get all top-level
classifiers from scopes imported by default, which includes typealiases.
Eager call to `getTypeAliasConstructors` here results in computing
constructors of the class descriptor on the RHS of the type alias, which
is not possible if that class is built-in, since the container has not
yet been created and thus `JvmBuiltIns` has not been initialized yet.
No tests added, and no issue is affected because, as mentioned above,
the problem is only reproducible if we add something to core/builtins.
useCorrectedNullabilityForTypeParameters = true only might lead
to something becomes a DNN when otherwise it wasn't.
It seems safe to use it here, since if compiler has generated DNN, then
it's OK to assume that it checked necessary conditions, and it's likely
that it had useCorrectedNullabilityForTypeParameters = true as well, there.
Anyway, it looks saner than having an exception here.
Also, we assume here that metadata leading to exception might only be generated
with ProhibitUsingNullableTypeParameterAgainstNotNullAnnotated LF
(at least, we don't have contradicting evidences),
thus it's mostly a preparations in case we decide to enable
ProhibitUsingNullableTypeParameterAgainstNotNullAnnotated in 1.9.
^KT-55357 Fixed
^KT-55388 Related
^KT-36770 Related
Previously, FIR used `_context_receiver_n` while FE10 used `<this>` for
all context receiver parameters. This commit changes the code in FE10
to follow the convention from FIR.
This is related to 8308f5d7d3 (KT-44977).
It turns out that it's necessary to create `ArrayValue` with a
precomputed type not only in case of annotations stored directly in
Kotlin metadata (i.e. annotations on types and type parameters), but
also for arguments of repeated annotations. The reason is that repeated
annotations are stored in an array themselves, as an argument to another
(container) annotation. The annotation-reading code unwraps this array
to load repeated annotations as individual instances of
`AnnotationDescriptor`, but in contrast to loading normal annotations,
it doesn't set `source` to the reflection object, it uses `NO_SOURCE`
(see BinaryClassAnnotationAndConstantLoaderImpl.AbstractAnnotationArgumentVisitor.visitArray).
So when kotlin-reflect is later asked for the arguments of the
annotation, it needs to recreate the reflection object from
`AnnotationDescriptor` in `util.kt`. Doing so requires knowing the array
type, which is now present because we're creating a `TypedArrayValue`
(previously `DeserializedArrayValue`) in places where arrays are read as
annotation arguments.
Alternative solution would be to fix source passed to
`AnnotationDescriptorImpl` in the annotation-reading code, but that
seems a bit messy because the code is very abstract and is used in lots
of other places.
#KT-53279 Fixed
Before this commit, we added Enum.entries only in case when
LanguageFeature.EnumEntries was ON (with an exception in K1/Java case).
In this commit we add Enum.entries unconditionally, and in case
the language feature is OFF we filter them out during tower resolve.
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).
But still compile stdlib, reflect, kotlin.test and scripting runtimes
with JVM target 1.6 to simplify migration from Kotlin 1.6 to 1.7.
#KT-45165 Fixed
KotlinCommonMetadata can be used to inspect .kotlin_builtins and
.kotlin_metadata files. It's in an internal package for now, but might
be published once the API is finalized.
Fixes KT-50992
DeclarationDescriptor.isInlineClass misidentifies inline classes without
constructors. This can happen for the ABI of inline classes with private
constructors.
so that defaults are available to synthetic implementations.
#KT-48181 Fixed
Implementation is for JVM IR; other backends & FIR need to be supported
separately.
Pavel Kirpichenkov