The default Jar task is disabled, but its archive file is still
configured as an artifact to be published in the 'archives' configuration.
Thus, neither 'install', nor 'publish' tasks could not find this file
when `libraryJarWithIr` isn't triggered and does not build it.
Removing that artifact from the 'archives' configuration artifacts makes
'install' task publish nothing.
Therefore it's better to revert the change so that 'libraryJarWithIr' task
always runs and produces an artifact with the default name.
This reverts commit a9fec211
After an inaccurate merge of 31936890 and d6ed93b2, this test was now
failing with the newly added assertion. It seems that currently the best
way to handle it would be to special-case these two methods in
SyntheticAccessorLowering.kt.
This is important for calls using reflection as the reflect
library assumes this ordering of arguments.
It would be nice if this could be handled in the lowerings.
Currently AddContinuationLowering is after
DefaultArgumentStubGenerator. If we could add the continuation
first and then do default stub generation maybe we could avoid
the reshuffling introduced in coroutine codegen in this change.
The first change here is swapping the isCompatibility and hasJvmDefault
checks. Otherwise behavior could be different depending on -Xjvm-default
mode even for non-JvmDefault declarations, which makes little sense.
Another change is avoiding generating $default stubs for fake overrides
in interfaces, which replicates the behavior of the current backend.
(Note that this change also fixes the first problem on the newly added
tests, but the first change seems useful anyway.)
Not sure if this affects real code, but this could happen in erroneous
cases such as in the subsequent commit, where it was a bit weird to see
this suffix without any supercalls involved.
This only reproduced when compiling (technically incorrect) code in the
standard library, where private functions monitorEnter/monitorExit are
accessed from another file, and their names with suffixes are not
recognized as intrinsics which should be replaced by
monitorenter/monitorexit JVM bytecode instructions.
This would help for example in debugging the issue fixed in the previous
commit.
The only problem by now where this lowering tried to add accessors to
foreign files was reproduced for interfaces inheriting from Cloneable.
There, we generate a DefaultImpls bridge that calls protected method
`clone` from java.lang.Cloneable.DefaultImpls. This makes no sense, but
the old backend behaves the same. Instead of generating accessor for it
in JVM IR, we now see all DefaultImpls bridges as public as a
workaround. (The fact that assertion no longer fails here is checked
e.g. by box/reflection/mapping/methodsFromObject.kt.)
Vladimir Dolzhenko