There's a flaky failures when
~/.m2/repository/org/robolectric/android-all/5.0.2_r3-robolectric-r0/android-all-5.0.2_r3-robolectric-r0.jar
is partially downloaded during tests execution.
This led to Parcelize tests failure with:
Caused by: java.util.zip.ZipException: invalid LOC header (bad signature)
at java.util.zip.ZipFile.read(Native Method)
at java.util.zip.ZipFile.access$1400(ZipFile.java:60)
at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:734)
at java.util.zip.ZipFile$ZipFileInflaterInputStream.fill(ZipFile.java:434)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158)
at java.io.FilterInputStream.read(FilterInputStream.java:133)
at java.io.FilterInputStream.read(FilterInputStream.java:107)
at org.robolectric.util.Util.copy(Util.java:21)
at org.robolectric.util.Util.readBytes(Util.java:38)
at org.robolectric.internal.bytecode.SandboxClassLoader.getByteCode(SandboxClassLoader.java:166)
... 36 more
Option used was found at https://github.com/robolectric/robolectric/blob/7697d1217c5eb0dee454004efe60ba219f398255/plugins/maven-dependency-resolver/src/main/java/org/robolectric/MavenRoboSettings.java#L19
^KTI-842 Fixed
Original `ComponentRegistrar` exposes Project to its registration method,
so plugins should manually register extensions to it. To prepare for
possible unbound compiler from Project API in future new `K2ComponentRegistrar`
introduced which provides registration method without Project at all
This is needed to avoid dependency on :compiler:fir:fir2ir module in
backend parts of compiler plugins. It will allow to publish those
parts into jars for IDE, where they are needed for working of debugger
and bytecode toolwindow
- `ParentAnnotatedWith` matches declarations, which parent is annotated
- `HasAnnotatedWith` matches declarations, which have at least one
direct child with annotation
Also, `DeclarationPredicate.Any` is removed, because there is no
intention to support lookup for all declarations in module
^KT-52486 Fixed
This is needed to avoid bundling of FIR classes to IDE plugin for
parcelize, because it can cause compatibility issues, because
IDE plugin does not contain FIR compiler
Move out utilities which are used both in lowerings and codegen to
JvmIrUtils and JvmIrTypeUtils, and introduce new JvmIrCoroutineUtils and
JvmIrInlineUtils (probably can be renamed or moved somewhere more
appropriate in the future).
In reality plugin key was used only in two ways:
- found corresponding generator for member scope of generated class
- pass it to declaration origin so it can be read in backend IR plugin
Because of first usage plugin key was required to be an object, which
reduces functionality of second usage, because there was no way to
pass any additional info via key to IR (in future this usecase will be
covered with IR declaration attributes, but right now we don't have
them)
So now generator which created some class is now saved in its attributes
and plugins can use any keys they want. And since there is no other
usages of `FirExtension.key` it removed from FirExtension API at all
After that commit it's allowed to register any FIR plugin using
existing extension infrastructure (`-Xplugin` CLI argument,
plugin.xml for IDE plugins, etc)
There is one of checks left unimplemented (FirParcelizePropertyChecker.checkParcelableClassProperty)
because it requires huge commonization of detecting which type can be
serialized and which not, which is not prioritized job for now
Steven Schäfer