In the desugaring for compound assignment to a collection element,
argument expression 'i' is mapped to value parameters 'iG' and 'iS' of
corresponding 'get' and 'set' operators.
In general, these value parameters can have different indices.
This requires extra machinery in argument generation - that is, to be
able to generate a particular expression argument using an arbitrary
callback. In the vast majority of the cases this callback will just use
the corresponding StatementGenerator to generate IR subtree for the
provided expression. In case of 'get' and 'set' operator calls for an
augmented assignment expression this will map corresponding argument
expressions to pregenerated temporary variables.
Thus, in the following context:
```
class A
operator fun A.get(vararg xs: Int) = 0
operator fun A.set(i: Int, j: Int, v: Int) {}
```
statement `a[1, 2] += 3` will be desugared as (in a really pseudo
Kotlin):
```
{
val tmp_array = a
val tmp_index0 = 1
val tmp_index1 = 2
tmp_array.set(
i = tmp_index0,
j = tmp_index1,
v = tmp_array.get(xs = [tmp_index0, tmp_index1]).plus(3)
)
}
```
Update jcabi-aether dependency from 0.10.1 to 1.0-SNAPSHOT. In order to
do that, add https://oss.sonatype.org/content/repositories/snapshots to
the repositories in tools/kotlin-script-util/build.gradle.kts
Script dependencies are resolved using jcabi-aether. Unfortunately "stable"
release (0.10.1) does not support proxies. Therefore, script dependencies
are not pulled behind a proxy. Issue is fixed in SNAPSHOT release of
jcabi-aether.
FIXED: KT-22363
Report about unsupported targets once per target type, show presentable
chunks list and don't show more then 5 chunks.
Example: "Native is not yet supported in IDEA internal build system.
Please use Gradle to build a, b, c, d, e and 10 other (enable 'Delegate
IDE build/run actions to Gradle' in Settings)."
#KT-26980 Fixed
#KT-28316 Fixed
1. Checking for COMPILE_DAEMON_CUSTOM_RUN_FILES_PATH_FOR_TESTS was moved to COMPILE_DAEMON_DEFAULT_RUN_DIR_PATH.
Looks like COMPILE_DAEMON_CUSTOM_RUN_FILES_PATH_FOR_TESTS was introduced incorrectly in 220fab0d3f.
Checking of this property was added in DaemonOptions.runFilesPathOrDefault, while DaemonOptions.runFilesPath was internally used in runFilesPathOrDefault and in many other places.
For example DaemonOptions.runFilesPath used to pass this option to daemon server.
So daemon was started with runFilesPath that ignores COMPILE_DAEMON_CUSTOM_RUN_FILES_PATH_FOR_TESTS.
2. JpsKotlinCompilerRunner._jpsCompileServiceSession was leaked between tests.
Fixed by extracting @TestOnly releaseCompileServiceSession() and calling it in tests tearDown()
3. The result of compileWithDaemon was ignored in compileWithDaemonOrFallback.
So, the fallback was never called, and the FAIL_ON_FALLBACK_PROPERTY was actually was never worked.
This was fixed. Also the message was improved to make it easier to find the original fail cause.
Gradle has a function `attributes { ... }` for `Configuration`, so we
can introduce one, too, for uniformity of the DSLs. This will configure
the `val attributes: AttributeContainer` of the `KotlinTarget` and
`KotlinCompilation`.
Issue #KT-27682 Fixed
* Add DSL for project(...) with path and configuration
* Add DSL for e.g. api(someDependency) { /* ... */ }
* Add DSL for e.g. api(kotlin("stdlib"))
Issue #KT-26663 Fixed
As Gradle Groovy DSL does out-of-the box not allow working with
SAM-receiving functions in the same way as those accepting a Closure,
and, moreover, does not work with Kotlin default parameters, we need
to provide Groovy-friendly DSL functions along with Kotlin DSL functions
This commit adds those additional members for all of the newly
introduced MPP DSL members.
In Gradle, a publication's Maven coordinates are by default derived from
the project. Setting them explicitly breaks the link, and the
coordinates are no more updated when the project's group and version
change.
Setting the coordinates in our code breaks with Gradle Kotlin DSL, where
the plugin is applied before the build script can even update the
project's group and version -- our code could set empty values, which
would update no more. Not setting them helps: the values are still
delegated to the project.
Gradle versions older than 4.10 could not correctly provide access to
the source set via delegation (i.e. `getting`, `creating` etc.) because
of the out-projection.
Remove the out-projection and expose just
`DomainObjectContainer<KotlinSourceSet>`, as under the hood we can still
use the `DefaultKotlinSourceSet` type for the items.
* Adjust some of the test tools to work with *.kts scripts
* Expose the tool for version substitution into plugins DSL and use it
* Transform the lib-and-app test case to Gradle Kotlin DSL
Previously, the connection between a `KotlinCompilation` and its
default `KotlinSourceSet` (the one automatically created and added into
the compilation) was not expressed in the MPP model in any reasonable
way that can be used in the build scripts.
However, this connection seems to have settled in the build logic, and
it may be useful to be able to get the default source set from a
compilation, for example, to be able to configure dependencies across
several targets in a uniform way.
The metadata compilations don't have their dedicated source sets, but
we can think of commonMain as a default source set for the project's
metadata, is it is currently in fact only contains the declarations from
commonMain.
Issue #KT-27685 Fixed
To simplify configuring a `KotlinCompilation` with Gradle Kotlin DSL, it
is essential to expose statically-known types where possible.
This commit parametrizes `KotlinCompilation` with its Kotlin options
type (a subtype of `KotlinCommonOptions`) and adds `kotlinOptions` and
`compileKotlinTask` to `KotlinCompilation`.
(minor) Also reduce the visibility of `attachClassesDir` and
`setupPlugins` to internal, since this API is not for external use.
This new interface uses a more general type for its kotlinOptions,
KotlinCommonToolOptions rather than KotlinCommonOptions. This is
needed for the Kotlin/Native task to implement a common interface
with the other Kotlin compilation tasks.
* Pull the `targets` and `presets` properties of the `kotlin` extension
up to an interface in `kotlin-gradle-plugin-api`
* Generate the code: we need type-safe statically-typed functions for
different target type, which seems to be only possible to achieve by
providing a function per preset.
* Place these functions in the top-level `kotlin` Gradle extension,
rather than extension functions for `kotlin.targets`:
- `kotlin.jvm { ... }` will work, while `kotlin.targets.jvm { ... }`
won't, the extension function needs to be somehow brought into scope
- reducing the nesting level by one seems to be a good move here
Issue #KT-26389 Fixed
Toshiaki Kameyama