DefaultConstructorMarker is used as a marker to ensure that a
constructor is unique for companion objects. Prior to this change,
DefaultConstructorMarker was package private.
Being package private worked when calling the
DefaultConstructorMarker-marked constsructor using `invokespecial`,
likely because the JVM may not perform strict access checks in this
situation.
However, when access checks are performed, trying to call a
DefaultConstructorMarker-marked constructor will fail. This could happen
if the constructor was called using reflection or the MethodHandle API.
These APIs may be used by tools that perform bytecode instrumentation
on Kotlin JVM bytecode, such as Robolectric. It also caused problems
when using ByteBuddy validation.
Fixes https://youtrack.jetbrains.com/issue/KT-20869
This makes 'test.' an implicit package prefix, thus fixing the inspection
"Package directive doesn't match file location" positive in almost all
test files.
Make Random.Default, XorWowRandom, and wrapper classes for JDK Random implement Serializable interface.
Co-authored-by: Ilya Gorbunov <ilya.gorbunov@jetbrains.com>
Report a separate error when class files compiled with FIR are in
dependencies, in addition to the one for class files compiled with FE
1.0 + JVM IR.
#KT-43592
This is a workaround for the problem KT-43321.
Introduce an intermediate abstract set specialized for Map.Entry elements
and implement 'contains(Map.Entry)' method there.
Then inherit that intermediate set in entrysets of JS HashMap,
JS LinkedHashMap, JVM MapBuilder, that are specialized for
MutableMap.MutableEntry elements, so that no override of 'contains' is
required anymore.
This allows to avoid incorrect special 'contains' bridge being generated
that otherwise rejects all arguments except ones of MutableEntry type.
Use String.indexOf(..., ignoreCase) instead in all branches to preserve
compatibility with behavior before 1.4.20 that used String.split which
essentially relied on that String.indexOf
#KT-43745 Fixed
The next step for JVM IR adoption in our project is going to be enabling
`kotlin.build.useIR`, but keeping `kotlin.build.useIRForLibraries`
disabled until we fix all remaining ABI incompatibility issues for
library code.
This lessens the possibility that kotlin plugin will get different
variants of builtins in the classpath, thus making builtins resources
loading less order-dependent.
Mikhail Bogdanov