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)
The point here is to disable the "checkNotNewerThanCompiler" check because it
breaks a real life use case of compiling with an old compiler against the new
runtime library (that may come implicitly as a transitive dependency of another
library). However, to keep the possibility of restoring this check in the
future without backporting the needed changes into the old branches, we now
only perform this check for the "Core" runtime components, and all other checks
-- for "Core" and "Main" runtime components. In the follow-up commit, we change
the runtime component of our libraries to "Main". If we decide we need the
"checkNotNewerThanCompiler" behavior in the future, we can change the runtime
component to "Core", effectively restoring this check in the old compilers
The -Xskip-metadata-version-check command line argument is supposed to be used
to avoid getting errors only; the side effect that it also caused compiler to
write the pre-release flag to binaries was a mistake and is fixed now
JvmPackagePartProvider should not just blindly load all multifile parts from
all libraries on the classpath, but only those from multifile classes which
shadow (come earlier on the classpath) other classes with the same name.
Otherwise if you have different versions of the same library (which uses
multifile classes) on the classpath, the compiler will see parts from both
versions. If some declaration have moved from one part to another, it's
possible to observe an overload resolution ambiguity error
#KT-15287 Fixed
Gradle can wipe system properties between the build.
If this property is not set, "idea.properties is not found exception"
can be thrown when creating KotlinCoreEnvironment.
LanguageVersion is an enum consisting of the current and all previous versions
only, so with it we won't be able to detect the language version of a future
runtime
Use "-Xno-check-impl" to suppress checking whether the platform declaration
implementation has the "impl" modifier.
Do not check presence of fake overrides from platform class in the impl class,
otherwise there would be a lot of errors about the fact that
equals/hashCode/toString are not marked with the "impl" modifier
Before creating a MetadataPackageFragment, check that the corresponding
directory (across the classpath) contains at least one .kotlin_metadata file.
Otherwise we're creating packages for every simple name queried during the
resolution and sometimes prefer a (empty) package to the existing class, for
example when the latter class is star-imported
Extract AbstractDeserializedPackageFragmentProvider out of
JvmBuiltInsPackageFragmentProvider and implement it a little bit differently in
MetadataPackageFragmentProvider. The main difference is in how the package
fragment scope is constructed: for built-ins, it's just a single scope that
loads everything from one protobuf message. For metadata, package scope can
consist of many files, some of which store information about classes and others
are similar to package parts on JVM, so a ChainedMemberScope instance is
created.
Introduce a bunch of interfaces/methods to deliver the needed behavior to the
'deserialization' module which is not JVM-specific and does not depend on the
compiler code: MetadataFinderFactory,
PackagePartProvider#findMetadataPackageParts, KotlinMetadataFinder#findMetadata.
Note that these declarations are currently only implemented in the compiler; no
metadata package parts/fragments will be found in IDE or reflection
Dmitry Jemerov