Add Char.MIN_VALUE and Char.MAX_VALUE implementations in primitive companion objects.
Update builtins test data and public API.
Co-authored-by: Oskar Drozda <themppsplx@gmail.com>
Set LATEST_STABLE language version and current version of stdlib to 1.3, set IS_PRE_RELEASE
Remove "EXPERIMENTAL" from 1.3 version description in tests and gradle options
A new method has been added in the Android Gradle
plugin 3.3.0. This commit switches from ussing the
MergeResources task, and uses getAllRawAndroidResources
API instead.
Test: manually verified
Before the new MPP, Kotlin source directories were added to the Java
source set's `allJava` and `allSource` by all of the Kotlin plugins,
including common and JS ones. As it turned out, this was required by the
IntelliJ Gradle import.
* Make all `KotlinSourceSetProcessor`s (not just JVM) check whether a
compilation has a Java source set and add the Kotlin source
directories to `allSource` and `allJava`
* Also disable the unclear resource `exclude` for the Java source set
that filters Kotlin source directories out of the resources
Issue #KT-26020 Fixed
Issue #KT-26267 Fixed
* Add dependency on KN shared in gradle-plugin
* Basic support for Kotlin/Native:
* Target presets
* Compilation into a klib
* Compilation into native binraies: framework and executable
* Basic dependencies between projects
* No jars in native publications
* Replace '-' with '_' in framework names
* Escape quotes in native command lines on Windows
* Move targets from Kotlin/Native repo
* Download KN compiler using Gradle's mechanisms
* Support source set dependencies in native
* Add configurations for consuming source sets metadata (extending the
source set's dependency configurations). These configurations will be
used by the IDE to pick up the dependencies metadata.
* Remove the universal preset from the default presets, create a
metadata target by default for compiling and publishing the metadata
of `commonMain` (in the future, we will publish and consume the
metadata of the other source sets as well).
* Make the classpath configurations of common modules consume the
metadata and thus ensure compatibility of 1.2.x MPP with the new MPP
model.
Before the last change in this logic, the resources filtering used
the original Kotlin source directories, not those with Java filtered
out.
Make sure that the Java source directories that are added to the Kotlin
source set are excluded from the resources, and all the related
configuration works lazily, i.e. supports source sets modification
after configuration took place.
It was placed in the new MPP plugin and was therefore not used for
the 'KotlinSourceSet's with the old plugin. Move this logic to the
KotlinSourceSetFactory so that it is applied to all source sets
Otherwise this code behaves incorrectly on getter-only properties: it
returns a meaningless field signature whereas the property has no field.
It's hard to come up with an example of when this could matter in
compiler code, but it's very noticeable in kotlinx-metadata-jvm
#KT-26188 Fixed
This should have no effect on the correct code currently because all
properties have at least a getter, but may help in debugging problems
with serialized metadata for properties
* Set canBeConsumed = false only on those configurations that have this
flag according to the Gradle Java plugins. This saves us from breaking
existing build scripts but introduces ambiguity between consumable
configurations (e.g. between `apiElements`, `compile`, `runtime`). See
the solution in the next point.
* Don't set the Kotlin platform attribute on configurations that are
not meant for consuming in other projects or resolving directly. This
change hides these configurations from Gradle's variant aware
dependency resolution and therefore prevents ambiguity
(cherry-picked from 81f2c48f)
Moved SubpluginEnviroment to separate file and made public some methods
KotlinNativeCompile task now extends AbstractCompile so it could be passed to SubpluginEnviroment.loadSubplugins
KotlinNativeBasePlugin now declares kotlinCompilerPluginClasspath configuration
* Add a platform type androidJvm that is one-way compatible (can
consume but cannot be consumed) with jvm, register the matching
strategy
* Write our attributes to Android's output configurations (this uses
a naming convention that Android inherits from Java, but there's no
public API at the moment for that)
Ilya Gorbunov