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
To prevent test failures once the JVM compiler stops loading definitions of
built-in declarations from itself and starts to rely on their presence in the
library, that the compiled source code depends on
- 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
This may be more correct in case of complex cross-module inheritance, where
overridability should be detected by structural equality of signatures instead
of referential equality of constructed descriptors (no test added because it's
not so easy to come up with an example)
In subsequent commits, a JVM module will be able to have up to two package
fragments for a given package FQ name. For example, for package "kotlin" in
kotlin-runtime.jar there will be a LazyJavaPackageFragment with binary
(Kotlin+Java) dependencies, and a BuiltInsPackageFragment for built-ins
metadata (which is loaded from kotlin/kotlin.kotlin_builtins)
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
Use it instead of mapPlatformClass where we only need to check emptiness
because mapPlatformClass requires built-ins and it's not always easy to come up
with the correct instance of built-ins.
In KotlinEvaluationBuilder, use the nullable function
findClassAcrossModuleDependencies instead of mapPlatformClass which uses the
throwing resolveClassByFqName. This is necessary because DefaultBuiltIns, which
are used there, are not always able to find classes mapped by a _Java_ to
Kotlin class map. (The correct solution would be not to use DefaultBuiltIns at
all, instead obtaining the correct instance of built-ins, which are almost
certainly going to be JvmBuiltIns, from the project configuration.)
Dmitry Jemerov