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.
Since `createStubBasedFirSymbolProviderForClassFiles` works for
builtins (after 866368cf), the provider sometimes has to handle
declarations from builtins (`Any?.toString()` or `arrayOf`, for example)
To provide correct origin for such declarations, we have to compute
the origin on the per-declaration basis instead of always setting
`Library` or `BuiltIn` origin
Providing correct origins should improve the consistency of
deserialized fir declarations
To reduce duplication, `getContainerSource` now also uses
`getDeclarationOriginFor`
If deserialized declarations from built-ins have a container source
which implements `FacadeSource`, it might cause different problems
during IR compilation.
For example, IR lowering of `Any?.toString()` function call was broken
because IR assumed that this declaration belonged to a facade class
"kotlin.kotlin", which does not exist.
We introduce a special kind of container source for the built-ins
declarations, and there are in fact no real facade classes for such
declarations.
Also, `LLFirModuleWithDependenciesSymbolProvider` is modified to
correctly handle such sources. Previously it only handled
`FacadeSource`s, and now it knows about our special source for
built-ins.
^KT-62859 Fixed
This fixes a false positive OUTER_CLASS_ARGUMENTS_REQUIRED when
referring to an inner class of a supertype that is extended using a
typealias.
#KT-62099 Fixed
Anton Lakotka