Also, require users of K2MetadataCompiler to pass "-Xmulti-platform"
manually. Gradle and Maven plugins already do that, so only users who
invoke kotlinc directly are going to be affected by this
#KT-19287 Fixed
* Support flags with any value (not just Boolean)
* Support all flags by parsing arguments in KotlinFacetSettings, instead
of manually listing known flags
#KT-19210 Fixed
There's no point in adding JDK (mock or full) roots to it, as well as
stdlib/reflect/test (they are loaded by the parent class loader, created
in ForTestCompileRuntime)
For tests with local delegated properties, this field is generated in
the full mode, but is not generated in the lite mode because local
variables are not analyzed properly in the lite mode
Also report the "named does not read unnamed" error, which was not
possible previously because we wouldn't be able to read anything from
kotlin-stdlib (because it was added to the unnamed module by default)
No package annotations are going to be loaded, and
TypeQualifierDefault/TypeQualifierNickname are no longer recognized by
default. Use the CLI argument "-Xload-jsr305-annotations" to enable this
behavior back
#KT-10942
It was only used for type-related nullability/mutability
annotations and it was necessary to remove them
in the descriptor renderer (duplicating their fqnames there).
At the same time they're only needed for types enhancement
where they can be simply restored from type owners' descriptors
The testData changes are more or less correct: this kind of annotations
is bound both to types themselves and their use because of their targets
Before this change, diagnostic tests with Java source files failed
because KotlinCoreEnvironment was being created in the test's setUp,
even before the test data file has been split into .java/.kt and the
resulting .java files have been copied to a temporary directory. In
KotlinCoreEnvironment's constructor, we now inspect all roots for
module-info files, which involves calling VirtualFile.getChildren on all
roots in the configuration. CoreLocalVirtualFile.getChildren is
cached on the first access, and so because the temporary directory with
.java files was empty at this point, the VirtualFile for that directory
returned empty array in getChildren later in the test, resulting in
unresolved reference errors.
This is fixed by creating the environment _after_ the .java files have
been copied to a temporary directory. Note that slow assertions for
flexible types are now enabled in KtUsefulTestCase instead of
KotlinTestWithEnvironmentManagement, because BaseDiagnosticsTest no
longer inherits from the latter
In this commit, only IDE tests are added, because we look for module
declarations in the IDE across the whole project, whereas in the
compiler we should do this on the module path only and that requires
separate work (KT-18599) which is done in the following commits.
(The change in Cache.kt is needed so that
JvmModuleAccessibilityChecker.ClassifierUsage, which is an inner class,
would be injected properly.)
#KT-18598 In Progress
#KT-18599 In Progress
Previously we traversed all notLoadedRoots on each request for package
parts with the given package FQ name. Since notLoadedRoots might contain
a lot of roots (which never transition into "loadedModules" because e.g.
they are not Kotlin libraries, but just Java libraries or SDK roots with
the META-INF directory), this was potentially hurting performance. It
seems it's more optimal to compute everything eagerly once
JvmPackagePartProvider is constructed.
Another problem with the previous version of JvmPackagePartProvider was
that it did not support "updateable classpath" which is used by REPL and
kapt2, it only used the initial roots provided in the
CompilerConfiguration. In REPL specifically, we would thus fail to
resolve top-level callables from libraries which were dynamically added
to the execution classpath (via some kind of a @DependsOn annotation).
In the new code, JvmPackagePartProvider no longer depends on
CompilerConfiguration to avoid this sort of confusion, but rather relies
on the object that constructed it (KotlinCoreEnvironment in this case)
to provide the correct roots. This is also beneficial because the
computation of actual VirtualFile-based roots from the ones in the
CompilerConfiguration might get trickier with modular Java 9 roots
- separate compileLibraryToJar into two public functions, for JVM and JS
- allow to pass any extra options instead of just -Xallow-kotlin-package
- add a bunch of default arguments for the most common cases
- Move the following from 'deserialization' to 'descriptors':
NotFoundClasses.kt
AdditionalClassPartsProvider.kt
ClassDescriptorFactory.kt
PlatformDependentDeclarationFilter.kt
findClassInModule.kt
- Move the following form 'descriptors' to 'deserialization':
BuiltInSerializerProtocol.kt
builtInsPackageFragmentProvider.kt
- Extract a marker interface from BuiltInsPackageFragment and move its
implementation to 'deserialization'
- Change the type of parameters in PlatformDependentDeclarationFilter
and AdditionalClassPartsProvider to ClassDescriptor
This will help in getting rid of the circular dependency of
'descriptors' <-> 'deserialization'
Write the modular JDK (9+) path to the module.xml file passed to the
compiler from the JPS plugin. This path is then recorded in the compiler
configuration in KotlinToJVMBytecodeCompiler.configureSourceRoots. This
is needed because in JPS plugin, we pass "-no-jdk" and thus no JDK home
path was recorded in the compiler configuration in
K2JVMCompiler.setupJdkClasspathRoots. Presence of JDK home path in the
configuration is crucial for JDK 9 support (see
KotlinCoreEnvironment.Companion.createApplicationEnvironment), because
classes there can only be loaded with the special "jrt" file system, not
as .class files in .jar files
#KT-17801 Fixed
baratynskiy