The test checks that new packages are not accidentally non-exported,
so each new stdlib package must be either exported or specified in that
test's expected non-exported package list.
We are going to deprecate `WITH_RUNTIME` directive. The main reason
behind this change is that `WITH_STDLIB` directive better describes
its meaning, specifically it will add kotlin stdlib to test's classpath.
Do not run kotlinc in a separate process in tests which check behavior
of the `kotlin` launcher script.
Locally, the test now runs for 37s instead of 51s.
See the class at org/jmock/Expectations
public <T> T with(Matcher<T> matcher);
public boolean with(Matcher<Boolean> matcher);
When we extending such class it we start assuming
that fake generic override overrides both of the overridden that is wrong
from POV of Java and it fails at FIR ultimate build
NB: It's hard to write a test because such Expectation-like
class is impossible to write in pure Java
Now, milestones of major Kotlin releases (e.g. 1.6.0-M1) will NOT
generate prerelease binaries anymore.
The reason for that is it's proven to be quite a complicated process to
turn on IR_PRE_RELEASE after the release is branched, perform double
bootstrap and fix tests, and then do it again in reverse just before
release. With the new release cadence, we don't have that much time to
do it and verify that everything works as intended.
Note that this only removes the "global" prerelease flag. Compiler will
still generate prerelease binaries if a non-stable language version is
used. For example, Kotlin 1.6.0-M1 with `-language-version 1.7` will
generate prerelease binaries.
Otherwise the test would invoke the "java" executable from PATH, which
might not be 1.8, and that would cause some tests to fail because error
messages are slightly different in newer Java versions.
Some of IDEA services (like in `com.intellij/execution`) was copied,
because they are used in tests but jars with them compiled with
jdk 11 and we run our tests on jdk 8, so their bytecode can not
be read
Use ClassLoader.getResource + openStream instead, to workaround an issue
in URLClassLoader.
Also set useCaches to false because kotlin-reflect only reads builtins
metadata once per class loader, and doesn't need it to be cached. Using
caches here might also lead to the problem of closed input streams when
protobuf is read in parallel. The test doesn't check exactly this,
though (it seems to succeed even if cached connections are used).
Note that BuiltInsResourceLoader has a JDK 9+ specialization at
libraries/reflect/api/src/java9, but that implementation does not need
any changes because it uses Module.getResourceAsStream which is not
affected by this issue in URLClassLoader.
#KT-18277 Fixed
Ensure that Gradle plugin dependencies do not include kotlin-stdlib,
kotlin-reflect and other dependencies that are provided by Gradle
runtime.
^KT-41142 Fixed
On Windows, the absolute file for the root of the drive is `"C:\"`,
which differs from the absolute file for any other directory, which
doesn't end with `\`. This resulted in incorrect trimming of the first
character of the path name in `descendantRelativeTo`.
Also, do not use canonicalPath because there is no point in expanding
symbolic links here.
#KT-40979 Fixed
Ilya Gorbunov