* The new idea-frontend-independent module created
* Moved KtReference and it inheritors to that module & implement them in idea-analysis module by using descriptors frontend
it conflicts with the compilation on daemon, so transistion should
be planned accordingly, and now it is not a good time for it.
The most important part of the renaming remains intact.
Partially reverts commit "Rename scripting libs and plugin - invert embeddable suffix"
now regular, unshaded libs, are named with suffix `-unshaded`, while
former `-embeddable` ones named without any suffix. This will encoursge
use of the shaded libs by default, avoiding conflicts with 3-party
libs packed into the `kotlin-compiler`.
Note, that only the "frontline" libs are renamed to avoid switching
problems, the ones that not normally used directly are left as is,
including the `kotlin-compiler` itself.
The :utilities module contains some logic that depends on all
other parts of the K/N toolchain. But we also need a module
containing a basic logic that all other parts of the toolchain
depends on. Historically such logic is located in the :shared
module. However having code with complex dependencies in :shared
may slow down a composite build import.
So this patch puts all content of :utilities into a new module
:utilities:cli-runner and creates a new :utilities:basic-utils
module. Later some logic from the :shared module may be moved
into this new module.
- Switch to building stdlib with bootstrap compiler since IR is stable
enough
- Build stdlib with coreLibs by default
- Include JS IR stdlib to kotlin distribution
Rename raw-fir:common to raw-fir:common -> raw-fir:fir-common.
If there's dependency both on :compiler:visualizer:common and
:compiler:fir:raw-fir:common, only one of artifact is left in classpath
tools.jar from JDK has different public api on different platforms which
makes impossible to reuse caches for tasks which depend on it. Since we
can't compile against those classes & stay cross-platform anyway, we
may just exclude them from compile classpath. This should make tools.jar
compatible at least within one build of JDK for different platforms
Compiler version changes every build and makes impossible to reuse
caches for heavy tasks such as compiler proguard. We may fix that by
adding version module directly to the final jar.
Vyacheslav Karpukhin