Setting `forkMode` to `ForkMode.NEVER` switches
`isolationMode` to `IsolationMode.CLASSLOADER`.
Classloader isolation mode prevented passing task's
logger to the unit of work.
Also it might resulted in multiple daemon instances starting
in parallel.
This change removes setting `forMode` (it was unnecessary).
Also a logger is used for the fallback message instead of printing it
to stderr. An assertion is added to tests, ensuring that
the fallback does not happen.
#KT-29394 Fixed
In general case, the module where built-ins are looked up
(builtInsModule) can have multiple package fragments corresponding to
the package "kotlin". Remove the misleading method
getBuiltInsPackageFragment along with its implementation details and use
the package view's scope instead (by changing
KotlinBuiltIns.getBuiltInsPackageScope), since it'll iterate over all
fragments accessible in the module and its dependencies.
The only difference between scopes of package fragment and package view
is that the latter also contains package views for subpackages, which is
why the change in BuiltInsReferenceResolverTest is necessary
Default built-ins represent built-ins loaded from the compiler jar via
class loader, and they may not be equivalent to the built-ins present in
the standard library that is used in compilation dependencies, in case
the compiler and stdlib versions do not match. Use built-ins from the
given module instead.
This commit deals with more-or-less obvious usages of DefaultBuiltIns;
next commits refactor the ESConstant values and related code to support
injected built-ins
Instead use a filter with a simple check. This seems to be slightly
better both for readability (`strictPartition` gave an impression that
two its parameters were related in some way, but they were totally
independent) and for performance (do not create unnecessary objects,
instead decompose the existing objects and check their structure)
- refactor appropriate functions to accept optional classloader (not used yet)
- try to load from thread context classloader first
- fallback to marker class classloader in the appropriate function
This script traverses all Gradle copy task, build virtual files model
and generates IDEA artifacts configuration based on this. Unfortunately
this is not fully working and needs manual fixing, so the actual artifacts
configurations are commited by hand for now. By the way, this script also
visits copy task's internals which leads that Gradle generates
manifests in `build` folders during IDEA import. This files are referenced
in artifacts configurations. So, despite the fact that artifacts
configurations created by this script is not used, we need to run them
to generate required manifests.
This solution will be replaced with DSL that produces both Gradle
copy tasks and IDEA artifacts configuration which is coming soon.
Mikhail Zarechenskiy