The main benefit are class-files sizes for them
(not repeating the same declaration for each coroutine)
Also it helped to simplify coroutine codegen code a little
Note that controller/label field become non-volatile (see KT-14636)
#KT-14636 In Progress
Provide a command-line option to load built-ins from the module and its
dependencies instead of looking for them in kotlin-compiler.jar; built-ins must
be found this way, or an error will be reported (or, most likely at this
moment, an exception will be thrown).
Note that this does not affect whether built-ins (loaded from one place or the
other) are added to the _dependencies_ of the module, this is controlled by
another option. The option added in this commit only makes the KotlinBuiltIns
instance which is used via ModuleDescriptor throughout the compiler front-end
(and also injected in a bunch of places) a sort of "helper" which always goes
to that same module to find descriptors for built-in classes
In AbstractPositionManagerTest, built-ins could no longer be resolved because
JvmIDEVirtualFileFinder is used in IDE tests (even when the compilation is
called through JvmResolveUtil/GenerationUtils as in compiler tests), which is
not yet able to locate .kotlin_builtins files
Introduce a new method KotlinClassFinder#findBuiltInsData, which is only
implemented correctly in the JvmCliVirtualFileFinder because it's only used in
the compiler code at the moment.
Introduce JvmBuiltInsPackageFragmentProvider, the purpose of which is to look
for .kotlin_builtins files in the classpath and provide definitions of
built-ins from those files.
Also exclude script.runtime from compilation because, as other excluded
modules, it has no dependency on the stdlib and is no longer compilable from
the IDE now, because it cannot resolve built-ins from anywhere
- In tests on built-ins with no sources, just call
JvmResolve.analyze(environment) and inspect the resulting module
- In AbstractLocalClassProtoTest, create container via
TDAForJVM.createContainer
- Inline single module container creation into AbstractDiagnosticsTest
Use the same approach that is used for creating function type classes
(Function{0,1,...}) + add Cloneable to supertypes of Array and primitive arrays
#KT-5537 Fixed
This is needed because SourceNavigationHelper uses default platform and it
needs default imports to be able to resolve references (otherwise
NavigateToLibrarySourceTestGenerated breaks)
Since its scope is now empty, no descriptor now has a container that is an
instance of IncrementalPackageFragment -> a lot of code is not needed anymore
Dmitry Petrov