All bytecode text tests are run with stdlib in the classpath and only
for JVM backend, therefore directives WITH_RUNTIME, TARGET_BACKEND,
IGNORE_BACKEND are not needed
Test data of crossinline_1_2.txt has changed because now we do not
automatically enable 1.2 (with _all_ of its features) when we're
executing a common coroutines test with old coroutines; and so the
NewCapturedReceiverFieldNamingConvention language feature (which is
introduced in 1.3) is now enabled in this test
Use `// !LANGUAGE: -ReleaseCoroutines` instead in tests which require
old (1.2) coroutines, and nothing in tests which require new coroutines
because master is already 1.3. Also remove superfluous API_VERSION and
other directives which have no effect anymore. Do not include runtime
automatically with `WITH_COROUTINES`/`COMMON_COROUTINES_TEST` in box
tests; require `WITH_RUNTIME` for that (majority of tests already had it
anyway), but remove it from bytecode text tests where runtime is always
added automatically. Fix the coroutine package selection code in
KotlinTestUtils and update the bunch files correspondingly.
Disable tests in `box/coroutines/noStdLib` on JVM: despite the name,
these tests were launched with stdlib because of the code in
CodegenTestCase, and they do not work without it because at least
CoroutineUtil.kt requires stdlib to compile correctly
Most of these tests used this directive as a way to opt in to a new
language feature, and most of those features are already stable for a
long time, so no opt-in is needed. Some other tests used the directive
to opt out from a language feature, replace those by the `LANGUAGE`
directive. One test used the directive to test behavior that actually
depended on the API version; use `API_VERSION` directive there instead.
See `ExpressionCodegen.genEqualsForExpressionsPreferIeee754Arithmetic`:
the behavior here actually depends on the API version, not any language
feature
- Drop unnecessary bunch files for `KotlinFacetType` and `KotlinFacetTypeImpl`
- Use cached val `isRunningInCidrIde` to check if the code is running under CIDR
#KT-28836 fixed
RMI messages are reported from RMI threads.
When Gradle logger is used from non-Gradle thread,
messages are not grouped in command-line
and they are not shown in build scans.
To fix this, we store all messages from Kotlin daemon
in a buffer, then report them from a Gradle thread.
In 1.3.0 only basic settings for final native binaries (e.g.
executables or frameworks) are available. They allow a user to
specify what kinds of binaries should be produced from one or another
compilation but they don't allow specifying different options for
different binaries or creating more than 2 (debug and release)
binaries of the same kind (e.g. executable) from the same
compilation. Also link tasks for these binaries are created after
project evaluation thus they are inaccessible for a user outside
of an afterEvaluate block.
This patch adds an extended binary DSL allowing a user to declare
binaries independently from compilations and to specify different
options (e.g. linker arguments) for different binaries. Also
link tasks for binaries declared in this DSL are created at a
configuration time so user can access them outside of an
afterEvaluate block.
Also this patch adds creating run tasks for all executables
declared in the buildscript (KT-28106)
Initial DSL methods for binaries declaration are still supported.
Kotlin DSL example is the following:
kotlin {
macosX64 {
binaries {
// Create debug and release executable with
// a name prefix 'Foo'.
// Two domain objects will be created:
// fooDebugExecutable and fooReleaseExecutable
executable("Foo", listOf(RELEASE, DEBUG)) {
compilation = compilations["foo"]
entryPoint = "foo.main"
linkerOpts.add("-Llib/path")
println(runTask.name)
}
// Name prefix and build types are optional.
// debugFramework and releaseFramework are created here.
framework()
}
}
}
Alexander Udalov