Before computing the FqName, check the simple class name first. This
code was responsible for about 20% of FqNameUnsafe instances created
during compilation of "core" modules
Instead of computing and comparing FQ names, compare simple names of
classes and theirs containers. This code was responsible for creation of
about 10% of FqNameUnsafe instances during compilation of "core"
modules.
Also make the check more strict: previously, a class "c" declared in
package "a.b" would be considered equal to a class "c" declared in class
"b" in package "a". Because JVM type descriptors of such classes are
different, this behavior was suspicious and might have lead to error at
runtime. Now, we require the number of containing classes of the given
two classes also to be the same
Reuse StringBuilder instances for nested subexpressions.
(NB StringBuilder instance for string template with a string
concatenation inside an expression entry, such as `"${"a" + "b"}"`,
will not be reused, although that doesn't seem to be a real-life issue).
#KT-18558 Fixed Target versions 1.1.4
#KT-13682 Fixed Target versions 1.1.4
Join adjacent strings literals, escaped strings, and constant values
(in a language version that supports const val inlining).
Use StringBuilder#append(char) for single-character constants
(e.g., " " in "$a $b").
#KT-17280 Fixed Target versions 1.1.4
#KT-15235 Fixed Target versions 1.1.4
If for some reason during preliminary analysis in redundant null check
elimination we failed to determine a local variable type statically,
treat it as java.lang.Object.
This will disable some further optimizations using precise type
information (such as INSTANCEOF check elimination), but will not fail
with an exception anyway.
This is necessary due to different modules can have same
package declarations. When importing declarations from these
packages, we should distinguish from which module we are importing it.
See KT-18652
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
Alexander Udalov