The CompilerMessageLocation is an implicit part of the binary daemon
protocol so changing it breaks compatibility with older daemons.
This change allows to extend location for non-daemon uses without
breaking the binary protocol.
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.
Revert "[JS IR] Build hybrid versions of stdlib and kotlin.test"
This reverts commit b9f88350dd.
Revert "[JS IR] Add gradle plugin integration tests"
This reverts commit d872b27663.
Revert "Update bootstrap"
This reverts commit bc47594c7a.
Revert "[JS IR] Support generating both IR and pre-IR libraries"
This reverts commit 1b8df45bfe.
The kotlin-scripting-compiler-impl jar is used in the idea plugin and
therefore should not depend on the cli parts of the compiler to avoid
dependency from the plugin to the kotlin-compiler.jar.
Therefore the cli-dependent parts were moved to the scripting plugin
jar, which is used only in cli compiler based environments.
Also implement required abstractions to allow this movement and
drop some redundant dependencies to the cli parts in other projects.
- implement wrappers to wrap old and new API providers and resolvers
- make old API deprecated (with error where possible)
- drop old internal classes related to the old API
- refactor usages accordingly
- fix and add missing features to the scripting API where necessary
In TopDownAnalyzerFacadeForJVM, we now always use the "load built-ins
from module dependencies" behavior that was previously only enabled with
the dedicated CLI argument -Xload-builtins-from-dependencies. However,
sometimes we compile code without kotlin-stdlib in the classpath, and we
don't want everything to crash because some standard type like
kotlin.Unit hasn't been found.
To mitigate this, we add another module at the end of the dependencies
list, namely a "fallback built-ins" module. This module loads all
built-in declarations from the compiler's class loader, as was done by
default previously. This prevents the compiler from crashing if any
built-in declaration is not found, but compiling the code against
built-ins found in the compiler is still discouraged, so we report an
error if anything is resolved to a declaration from this module, via a
new checker MissingBuiltInDeclarationChecker.
Also introduce a new CLI argument -Xsuppress-missing-builtins-error
specifically to suppress this error and to allow compiling code against
compiler's own built-ins.
#KT-19227 Fixed
#KT-28198 Fixed
1. Use 'KaptOptions' for all kapt options, including paths and flags.
2. Use a single 'KAPT_OPTIONS' compiler configuration key for setting all options (using a mutable KaptOptions.Builder).
3. Pass 'KaptOptions' instead of separate flags.
4. Remove 'KaptPaths'.
5. Remove deprecated 'aptOnly' CLI option.
since it causes numerous classloading issues. Using the wrapping types
and reload them in the proper context when needed.
Note: this version supports only classes, but the wrapping type could
be extended to support other types in the future.
+ numerous fixes related to proper loading and handling of the templates.
Using the new multi-release jar feature, store compiled
module-info.class files into META-INF/versions/9 instead of the artifact
root. Hopefully, this will break fewer tools which do not support
module-info.class files because any sane tool should not do anything
with files in META-INF because before Java 9 that directory only
contained resources.
Upgrade some Maven plugins to newer versions which do not fail on
module-info.class files
#KT-21266 In Progress
Ilya Chernikov