We cannot create kapt configurations in `KotlinGradleSubplugin.apply`,
because `apply` is invoked after a script is evaluated, so user cannot
refer to kapt configurations in script.
We cannot call `apply` before script's evaluation, because
then we might not be able to determine
if a Gradle plugin corresponding to a subplugin is appled.
For example in case of the following script:
```
apply plugin: "kotlin"
apply plugin: "kotlin-kapt"
```
subplugin's apply will exit early because Gradle plugin "kotlin-kapt"
is not applied yet, when "kotlin"'s apply is evaluated.
since it causes numerous classloading issues. Using the wrapping types
and reload them in the proper context when needed.
Note: this version supports only classes, but the wrapping type could
be extended to support other types in the future.
+ numerous fixes related to proper loading and handling of the templates.
This commits adds a new annotation OptionalExpectation to the standard
library, which is experimental. To enable its usage, either pass
'-Xuse-experimental=kotlin.ExperimentalMultiplatform' as a compiler
argument, or '-Xuse-experimental=kotlin.Experimental' and also annotate
each usage with `@UseExperimental(ExperimentalMultiplatform::class)`
#KT-18882 Fixed
Also remove these option providers from the javac task compiler argument
providers so as to avoid output intersections of javac vs kapt.
The options generated by the providers are added to the Kapt subplugin
options as well in order to be passed to Kapt. Since these options
are a list, not a map, pass them without name (Kapt should decode them
into plain arguments). Remove the '-A' prefix as it is there for
command line annotation processor options, but we don't need it, it
is added by Kapt internally.
Issue #KT-23964 Fixed
Issue #KT-24420 Fixed
It's no longer needed for checking binary compatibility.
Clean build of these libraries is no longer required too.
Cleanup build.gradle of binary-compatibility-validator.
It's no longer required to dump kotlin-to-java declaration mapping to json
before using binary-compatibility-validator.
@JvmOverloads are not supported yet, so remove them from test.
Use asm:6.0 in bcv
Each Kotlin task now writes build history to separate file.
A map of output directories to history files is used to get changes for
modified files.
#KT-22623 fixed
- rename object Flags to Flag and merge it with MetadataFlag
- use typealias Flags instead of Int
- use top level function "flagsOf" instead of "Flags.invoke" to
construct a bitmask
#KT-23198
Previously some Kotlin files were recompiled, because Java files
were regenerated.
However this is no longer true for some time since
precise Java tracking was implemented.
Adds Gradle test for the exception:
`java.lang.ClassNotFoundException: net.jpountz.lz4.LZ4Factory`
The exception breaks IC in Gradle. Gradle compiles non-incrementally as
a fallback strategy, so the build succeeds, but IC is not working.
IC uses persistent hash tables from Intellij as caches.
These tables's buffers are compressed when full.
Previously snappy was used for compression, but 181 platform switched to
LZ4, which was cut out by proguard.
The problem could only be reproduced with Gradle,
since in JPS plugin all caches are managed by JPS process,
which contains the necessary library.
To reproduce the compiler needs to be processed by proguard
(which always happens on TeamCity).
Many classes are needed to trigger the compression.
Since Android considers the `compile` configuration as deprecated and
reports a warning when a dependency is added to it, use the `api`
configuration when dealing with an Android platform module.
Issue #KT-23719 Fixed
This addresses the cases when a module name contains a slash
(e.g. when the Gradle project name was set this way to point
Gradle to the directory), which led to Kotlin module file being placed
under a subdirectory of META-INF and thus undiscoverable for the
compiler and reflect.
Additionally, this fix removes characters \n, \r, \t whose
presence in a module name caused compilation failures.
Issue #KT-20608 Fixed
KaptTask was not declaring the compiler classpath (which it takes from
compileKotlin task for calling the compiler) as input. This commit fixes
that and adds a test that checks compiler classpath input checks for the
kapt tasks.
Issue #KT-23879 Fixed
Since the custom source sets may be added after the plugins are applied in both common and platform module, we need to handle `.all { ... }` source sets in both modules and add common sources to the platform module once a match is found.
Issue #KT-22510 Fixed
Since we're not yet sure of the design of Experimental/UseExperimental,
we're making them "experimental" themselves in some sense, in that the
user is required to provide the magic argument
"-Xuse-experimental=kotlin.Experimental" to be allowed to use either
Experimental or UseExperimental. This is more convenient than the
previous approach of "-language-version 1.3
-Xskip-metadata-version-check" because it's simpler and does not cause
pre-release binaries to be produced
Alexey Tsvetkov