There was an exponential complexity in case we have a chain
of nested LexicalScopeWrapper instances:
we were walking through the chain and on each step running
the algorithm recursively.
Such a case is possible in scripts where each line contains LexicalScopeWrapper
The fix looks safe to me because delegate was used there
for checking !is ImportingScope && !is LexicalChainedScope
In all other means, being recursively run the algorithm does the same job.
#KT-22740 Fixed
Make ScriptDefinitionProvider an interface
and provide different implementation for cli and IDEA
Rework ide extension point to a simpler interface (ScriptDefinitionContributor)
Move template loading logic into a top level function
Allow script definitions to be reloaded in IDE
The main changes are in jvm_package_table.proto and ModuleMapping.kt.
With JvmPackageName, package parts can now have a JVM package name that
differs from their Kotlin name. So, in addition to the old package parts
which were stored as short names + short name of multifile facade (we
can't change this because of compatibility with old compilers), we now
store separately those package parts, which have a different JVM package
name. The format is optimized to avoid storing any package name more
than once as a string.
Another notable change is in KotlinCliJavaFileManagerImpl, where we now
load .kotlin_module files when determining whether or not a package
exists. Before this change, no PsiPackage (and thus, no JavaPackage and
eventually, no LazyJavaPackageFragment) was created unless there was at
least one file in the corresponding directory. Now we also create
packages if they are "mapped" to other JVM packages, i.e. if all package
parts in them have been annotated with JvmPackageName.
Most of the other changes are refactorings to allow internal names of
package parts/multifile classes where previously there were only short
names.
E.g. "kotlinc foo.kt test/Bar.java" will compile foo.kt, and
declarations from Bar.java will be accessible to Kotlin code in foo.kt.
The change in AbstractTopLevelMembersInvocationTest is needed because an
incorrect configuration was created in that test where a library jar was
also a Java source root (the compiler is never configured this way in
production), which led to an exception in
JavaCoreProjectEnvironment#addSourcesToClasspath
#KT-17697 Fixed
By default we use the fast implementation in CLI compiler,
but in the most of the tests the old one is enabled
Also add tests on CompiledJava with the fast class reading
implementation
It seems to be very natural refactoring considering the
following changes: optimizing KotlinCliJavaFileManagerImpl.findClass
to make it read class files manually instead of requesting PSI
Overhauls the scripting layers (GenericRepl and related, and JSR223 and related)
Adds repeating modes (none, only latest eval'd line, or random order)
Also adds better thread-safe IO capturing, default imports, SimpleRepl wrapper, more unit tests
NOTE: the script-util part of the pull request was rejected due to various problems and incompatibilities.
It may be incorporated into the code later.
(originally cherry picked from commit 6f7d517)
Ilya Chernikov