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