We should not expect builtins to be always available as they are taken from indecies.
For K1 and FIR Standalone implementations, the builtins are always available.
^KT-62010 fixed
Since they are not `FirSmartCastExpression`s,
they are treated as proper original types,
thus leading to reporting errors instead of
warnings.
^KT-60095 Fixed
Also, remove setting the value of allowUnstableDependencies to true if
K2 is used because we want K2 to report errors (as K1 does) on
unstable-ABI dependencies.
#KT-61598 Fixed
Currently, PROPERTY_WITH_NO_TYPE_NO_INITIALIZER is reported for local
variables, but not reported for member or top-level properties. Add a
check to the common `checkPropertyInitializer` for when a property
type cannot be determined from the getter.
This also corrects a K1 versus K2 inconsistency, where K2 would allow
blocks from getters to determine property type instead of only allowing
expression bodies.
^KT-59935 Fixed
^KT-60117 Fixed
^KT-60123 Fixed
Even when createDefaultMultiplatformPublications=false and maven-publish
is applied it is required to create all publication-specific entities
such as tasks, configurations, components etc. In order to let users
to compose publications on their own.
^KT-62877 Verification Pending
Previously it was attached to RootSoftwareComponent which has
heavy initialization work, for instance it creates new configurations
upon creation. The `publicationDelegate` is used in
`idOfRootModule` and should not trigger RootSoftwareComponent
initialization. After the change `idOfRootModule` became cross-project
safe. I.e. Project `foo` can call `idOfRootModule` on project `bar`.
^KT-62877 Verification Pending
^KTIJ-27374 Verification Pending
Mutating projects data, particularly, adding new items to its
collections such as tasks, configurations and components is a potential
risk to lose these data during the import to IDE.
^KT-62877 In Progress
It's confusing + it's not really
correct. It checks properties of
LUB types rather than the original
ones, but if we want to replicate
K1, we should check the originals.
1. Don't need to print stack trace on trivial errors such as invalid
CLI argument or incompatible library version.
2. Re-organization of `logWarning()` & `logError()` calls inside
the klib tool.
Ilya Kirillov