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.
Simplify MultifileClassPartCodegen, remove related tests and change some
tests to use const val instead of val because backing fields for const
properties are stored in the facade, not parts
#KT-23701 Fixed
Alexander Udalov