It affected the changed test in the following way: "strict metadata
version semantics" is a flag which is written to the .kotlin_module file
between the version and the protobuf data, see `ModuleMapping:73`. But
flags are written only for Kotlin 1.4+, i.e. if `isKotlin1Dot4OrLater`
returns true. So in the test, the flag was not written, thus we did not
detect that the module actually has incompatible metadata, and thus
incorrectly did not report an error.
It also has an effect that version requirements for nested classes will
now be written correctly to protobuf with metadata version 2.0+.
Using `ReflectionProperties.lazy` is incorrect because it allows several
threads to observe different resulting values if they're computing it
simultaneously (unlike `lazy(PUBLICATION)`, which always returns the
value that "won the race").
In the case of property delegates, for example, if we're invoking
`isAccessible = true` and then `getDelegate()` concurrently, it might
happen that when some thread invokes `getDelegate()`, it gets the
underlying Field object which was written by another thread and which
has not yet been made accessible, leading to
IllegalPropertyDelegateAccessException.
#KT-27585 Fixed
- Make the implementations very similar, to fix KT-54833 where the
companion object case was forgotten for kotlinProperty.
- Optimize both functions to look up the function/property by name
first, to cover the most probable case when the JVM name of a
declaration is equal to its Kotlin name. This fixes KT-55937.
#KT-54833 Fixed
#KT-55937 Fixed
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.
With this flag we can distinguish enum classes that have `entries`
property in the compiled bytecode (see `LanguageFeature.EnumEntries`).
This is needed to be able to understand in the frontend whether
`entries` can be called for that class. For Native and JS, this is
currently not possible even if the feature is enabled, but the class
was compiled with disabled feature.
^KT-53929 Fixed
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.
Initially, it was added accidentally as part of e3f987459c
and missed all out processes.
Adding @SinceKotlin("1.7") after the annotation has already been
published before is not really a problem, because it only may be used
with an experimental `-Xcontext-receivers` flag, thus it doesn't have
to be a part of our regular backward compatibility routine.
^KT-55226 Fixed
TypeRegistry is the static map which contains mapping between type of
session component and its index in the session array. Originally
`KClass` of a component was used as a key in this map, which worked
pretty well for compiler components. But there was a problem with
components from plugins and Kotlin daemon: in compilation with daemon
we keep TypeRegistry between compilations. But for each compilation
we load plugins from jar, which brings to the situation when after N
compilations there is N entries in TypeRegistry map with different
KClass'es for same extension component. This not only causes AIOBE
but also introduces the memory leak, because we keep reference to
KClass which is not used anymore
So to fix this issue it's enough to just store FQN of component in
TypeRegistry instead of KClass
There are no tests in this commit, but they will be added in next
commit relevant to scripting. With those commits we will have gradle
integration tests which uses Kotlin compiler daemon and registers
a compiler plugin for scripting
^KT-55023 Fixed
Alexander Udalov