IR expressions are left out for now, because unlike declarations,
which are mostly created via IrFactory, expressions' constructors are
widely used, and it's hard to replicate the exact signatures of those
constructors with the tree generator.
Therefore, some other approach is expected to be taken when generating
them in the future.
^KT-65773 In Progress
instead of inside implementation configuration.
Whether a field is a child element is a core concept of the tree,
not a matter of particular implementation class.
It is especially visible in IR tree, where the base classes implement the
acceptChildren method. It will also be more relevant in the future.
This also aligns the config style between IR and FIR tree generators.
^KT-65773 In Progress
Adds new warning diagnostic that checks that selected Xcode version is not higher than latest tested with the current Kotlin version
^KT-62373 Verification Pending
This diagnostic is reported in rare situations when
StubTypeForBuilderInference is kept as a parameter type
of for loop or lambda. Before this commit, we had in K1
"Could not load module <error module>" from IrLinker instead.
Related to: KT-52757, KT-53109, KT-63841, KT-64066
#KT-53478 Fixed
There are two different objectives associated with this newly
introduced extras:
- originClassId: Used to track where a type came from; Will
ensure that the translation queue will be populated to also
translate potential dependency classes
- requiresForwardDeclaration: Used to track if a certain
type requires rendering as forward declaration
KT-65891
- findCurrent() is used by the build of Kotlin/Native compiler itself.
It happens indirectly, via AppleConfigurables.
- CurrentXcode invokes xcrun command line tool in its implementation.
- Configuration cache prohibits calling external commands
All three factors combined make K/N compiler build incompatible with CC.
By using xcodeOverride, K/N compiler build can provide its own Xcode
instance avoiding calling external commands when it's not allowed by CC.
There are two types of type lists that can be met in Kotlin metadata
and that should be treated in a different way:
1. The order-sensitive type list. Examples: Context receivers.
2. The order-insensitive type list. Examples: Class supertypes,
type parameter upper bounds.
With (1) swapping elements in list causes source and/or ABI
incompatibility, while with (2) it does not. If it happens that we
compare two type lists in Kotlin metadata of (2) kind, we should group
them using the key computed with the help of
`dumpToString(dumpExtras = false)` instead of just the index as we do
in case of (1).
^KT-62753
Sebastian Sellmair