The previous implementation would return a 'SharedCommonizerTarget'
containing just a single leaf target. This would trigger the commonizer.
The new implementation will correctly return just a single
LeafCommonizerTarget instead.
^KT-49735 Verification Pending
Previous episode was at 987a3460 (KT-45915).
Apparently, it's not enough to run psi2ir for all modules, and then
backend for all modules. If there are several modules in the chunk, IR
in any one of them can reference IR of any other one after psi2ir.
So we would end up in a situation where we're running codegen for the
first module, but the second module is completely unlowered. This would
break some assumptions in the codegen, for example in KT-49575, codegen
would see a reference to a top-level function from another module, and
would fail because the function has no containing class (since file
facades have not been generated yet!), and thus must be an intrinsic,
yet no such intrinsic is known to the codegen.
The solution is to run lowerings first on all modules, and then run
codegen on all modules. The kind of error explained above shouldn't be
possible anymore, because lowerings have to deal both with lowered and
unlowered code from other files all the time, so lowerings can't assume
that reference from other module is lowered either (or unlowered).
The code is not very nice, but hopefully it can be improved as soon as
we get rid of the old JVM backend (and maybe later with the migration to
FIR too).
#KT-49575 Fixed
This is needed in order to be able to invoke lowerings and codegen
separately, for cyclically dependent modules (KT-49575).
A side effect is that the two codegen phases are no longer configurable
via the phaser, i.e. absent in the -Xlist-phases and can't be disabled
or made verbose.
This will be used for two purposes:
1) call lowerings and codegen separately from
KotlinToJVMBytecodeCompiler to support cyclical module dependencies
(KT-49575)
2) split lowerings and codegen into separate modules
Instead, document that `KType.annotations` returns an empty list for
types created with `typeOf`. Annotations might be supported in the
future.
#KT-49573 Fixed
#KT-29919
This is needed to avoid problems with checking visibility of types which
are used in supertypes during supertypes resolution in IDE, when
supertypes of some class can be already computed, but not saved in
class itself, but still lay in supertypeComputationSession
There were 4 failing tests before this changes (all in
`DiagnosisCompilerTestFE10TestdataTestGenerated$Tests$Exposed`):
- testInternal
- testInternalAndProtected
- testProtected
- testProtectedSameWay
Scope.createTemporaryVariableDeclaration has default values for
startOffset and endOffset parameters, which are UNDEFINED_OFFSET.
This is error-prone. Caller should typically be able to pass proper
offsets. If not, let using undefined offsets at least be explicit.
Remove default values for startOffset and endOffset parameters in
Scope.createTemporaryVariableDeclaration
The variable generated by IrStatementBuilder.irTemporary doesn't inherit
startOffset and endOffset from the builder. In particular, as a result,
temporary variables generated for elvis operator left operand have
UNDEFINED_OFFSET.
Additionally, ProvisionalFunctionExpressionLowering copies the offsets
of a variable to lowered lambda in the variable initializer. With the
problem described above, this causes invalid debug information in
Kotlin/Native, see KT-49360.
Fix irTemporary by using builder's offsets for the variable.
^KT-49360 Fixed
The kdocs were almost self-evident, as opposed to the fact that
JvmClasspathRoot is unused in the project, which could make it a victim
of an innocent refactoring.
There's a source and javadoc validation in sonatype that
once *-sources.jar or *-javadoc.jar is found expect main
jar must be present as well.
This doesn't work when instead of jar we publish klib.
Prior to this change a 'Collection is empty.' error was reported
when the Android plugin was applied without an Android Kotlin target
being registered.
^KT-41641 Verification Pending
Actually, there is nothing wrong with calling commit() again: Some TestFiles are created as uncommitted and require calling commit(), while others are created as committed from the very beginning.
sebastian.sellmair