- 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
- Introduce Ir-based Functional interface factory
- Switch from LazyIr to pure
- Use kotlin library to access raw bytes
- Link dirty files against IC cache and dependencies instead of LazyIr
- Move `DescriptorByIdSignatureFinder` from K/N to common
- Support inline-bodies only MODE
removes classloading problem when main-kts is loaded from a CL
without scripting compiler.
Also relax dependencies collection on saving to a jar and hide redundant
logging.
Running main.kts script via a run configuration works now.
#KT-37765 fixed
Now SymbolTable operates with two types of symbols (public and private)
In case of Public symbol IdSignature is used as table key
Private one uses descriptor as the key in similar scheme as before
#KT-35740 fixed
also add tests and drop logger usage in the cli dependencies manager:
the logger is normally unitialized in the usage scenarios, but related
warnings are annoying.
Previously JS IR versions of stdlib and kotlin-test were build
by default using compiler previously built on a buildserver.
It had some issues:
- This required us to advance bootstrap every time we made any
incompatible IR changes. This happens often since IR ABI is
not quite stable yet.
- We never tested the exact combination of compiler and stdlib we publish
We tested:
- new compiler with new stdlib build by new compiler (in box tests)
- old compiler with new stdlib build by old compiler (in stdlib tests)
We published:
- new compiler with new stdlib build by old compiler
After this change JS IR compiler tests, builds and publishes
single configuration:
new compiler with new stdlib build by new compiler
JS IR stdlib and kotlin-test are now built using JavaExec of CLI instead
of Gradle plugin to avoid troubles of loading a freshly built plugin.
This also allows to have a granular dependencies: we don't rebuild klib
if we changed a lowering in a compiler backend, but we do rebuild it if
we changed IR serialization algorithm.
This is a refactoring to simplify the API of
ExternalDependenciesGenerator and to constrain future additions of
platform-specific stub generator extensions.
since we're not always use jna (means that we can get warnings about missing jna libs)
and according to the IDEA team, NIO2 works well enough to rely on it
