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
Report type mismatch on argument when a nullable argument is passed to non-null parameter.
Note that this affects only functions with simple types without generics
#KT-2007 Fixed
#KT-9282 Fixed
Since the kotlin-reflect artifact might be used in environments where
the kotlin-stdlib artifact is named something else (e.g.
kotlin-stdlib-{version}.jar) and the file existence is verified by the
launcher
#KT-16399 Fixed
This fixes the exception in the case described in KT-14094 because we no
longer try to load annotations on functions which cannot be annotated
with @PlatformDependent. (However, the underlying problem in KT-14094 is
not fixed by this, and is still reproducible on explicit call to
KCallable.annotations.)
#KT-14094 In Progress
Class.getMethod does not return protected methods from super class, so
we invoke getDeclaredMethod on each super class manually instead
#KT-18480 Fixed
KotlinBuiltIns.isConstructedFromGivenClass checks the simple name of the
class first, and only computes the full FQ name if it matches the last
segment of the expected FQ name
Alexander Udalov