In TopDownAnalyzerFacadeForJVM, we now always use the "load built-ins
from module dependencies" behavior that was previously only enabled with
the dedicated CLI argument -Xload-builtins-from-dependencies. However,
sometimes we compile code without kotlin-stdlib in the classpath, and we
don't want everything to crash because some standard type like
kotlin.Unit hasn't been found.
To mitigate this, we add another module at the end of the dependencies
list, namely a "fallback built-ins" module. This module loads all
built-in declarations from the compiler's class loader, as was done by
default previously. This prevents the compiler from crashing if any
built-in declaration is not found, but compiling the code against
built-ins found in the compiler is still discouraged, so we report an
error if anything is resolved to a declaration from this module, via a
new checker MissingBuiltInDeclarationChecker.
Also introduce a new CLI argument -Xsuppress-missing-builtins-error
specifically to suppress this error and to allow compiling code against
compiler's own built-ins.
#KT-19227 Fixed
#KT-28198 Fixed
1. If header contents are identical, don't write all of them
in the resulting header. Just write content of one of the
headers without #ifdef-s.
2. Use #elif to separate declarations for different platforms.
Previously the CocoaPods plugin assumed that Gradle wrapper
is located in the project directory. But the project may be
a part of multiproject build and wrapper may be located in
the root directory of such a build. Also the build may not
have the wrapper at all.
This patch looks for the wrapper in the root directory of the
build and runs the local Gradle if there is no wrapper.
Building for old iOS devices requires us to provide fat
arm32/arm64 frameworks. This patch uses the fat framework
task to build such a framework and provides it to Xcode
if a build for a device is executed. In other cases
(building for iOS simulator or macOS) simple frameworks
are still used.
and refactor tests
#KT-27051 fixed
this commit is just a confirmation of the fix: either it worked
from the beginning, or was fixed by some unrelated change
add support for artifacts with type an classifier
use ibiblio resolver by default - it is designed for working with maven central
add test, but disable it - see comments for the reason and todos
From KOTLIN-CR-2801 reasons to move:
- I've changed repo layout and build process in incompatible way and decided to change location
- It was difficult to find and annoying to locate, it was very deep and long path
- I think dependencies/repo path is very easy to remember and find
- It was called dependencies some time ago
@Parcelize is now enabled by default, and it requires the runtime library.
Enabling it for all clients is a temporary solution.
In future, the runtime library will be split to two separate artifacts.
Once set of dirty symbols is computed, filter these types
when they are requested from the JavaFileManager. This is accomplished
by tracking all declared types in the sources and generated sources.
It is not necessary track types in generated class files, as these will
be removed before the APs are incrementally run.
Motivation: APs (e.g. Dagger) may use Elements.getTypeElement(String)
to determine if type is already present, and if it is, they will not
generate it. Therefore, whenever generated sources is invalidated, types
it defines need to be filtered in the JavaFileManager.
Issue is https://youtrack.jetbrains.com/issue/KT-23880
Add support for incremental annotation processors in KAPT. These
processors conform to https://docs.gradle.org/current/userguide/java_plugin.html#sec:incremental_annotation_processing
specification.
Support is provided by using javac compiler APIs and
recording the source file structure. At runtime, processors
are instrumented with custom Filer that is used to keep track of generated
files. In order to support classpath changes, stub generation task is
used to generated a list of changed FQCNs, and this is simply used by KAPT.
Both worker and non-worker mode are supported.
#KT-23880
As the Gradle Java plugin considers Java annotation processing cacheable
with any annotation processors, we can enable build cache by default
for Kapt tasks, leaving the opt-out flag just in case.
Issue #KT-27675 Fixed
When Android Java 8 desugaring is set as follows (or above):
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
set the Kotlin JVM target to 1.8
Issue #KT-21030 Fixed
This is the Gradle plugin that does not rely on the
Java model and uses the same Kotlin model
(target – compilation – source set) as MPP does.
Also add JS DCE support for this plugin.
Issue #KT-5756 Fixed
Issue #KT-13256 Fixed
Issue #KT-16355 Fixed
Issue #KT-20156 Fixed
Issue #KT-29284 Fixed
The attributes applied by the user to the target and its compilations
were ignored in single-platform plugins while the target was not a part
of the API.
Since the user will be able to access and configure the target, we need
to apply the attributes to the relevant configurations in the same way
as in MPP.
In MPP, the disambiguation classifier is always the same as the target
name. In single-platform projects, the task name suffix should be empty
for the JVM targets. Using the `disambiguationClassifier` for this
purpose is more consistent with other usages of
`disambiguationClassifier`.
The target name for all existing single-platform plugins will be just
'kotlin'.
Alexey Tsvetkov