This will include Internal* and *Experimental annotations for the
Kotlin Gradle Plugin. The separate module is proposed, so that
additional modules can use those annotations without
a dependency to the full kotlin-gradle-plugin-api module
(see -idea modules)
^KT-54029 WIP
Now KotlinNativeLink task does not extend AbstractKotlinNativeCompile
task as Link task is tool type task that should use
CompilerCommonToolOptions.
^KT-27301 In Progress
Currently know problematic place is in 'common-configuration.gradle.kts'
setting '-Xklib-relative-path-base'. This is done in task doFirst{}
action to avoid remote build cache misses due to absolute path usage.
^KT-27301 In Progress
Currently know problematic place is in 'common-configuration.gradle.kts'
setting '-Xklib-relative-path-base'. This is done in task doFirst{}
action to avoid remote build cache misses due to absolute path usage.
^KT-27301 In Progress
Move tasks configuration into JS tasks configurators.
Introduce enhancedFreeCompilerArgs workaround when freeCompilerArgs
are modified based on existing values.
Introduce workaround for 'destinationDirectory' input when it
content are depenends on multiple other task inputs.
^KT-27301 In Progress
Currently, known plugins doing that are 'kotlin-dsl' and AGP with
compose enabled. They are setting freeCompilerArgs in KotlinCompile
.doFirst task action. At this point compilerOptions.freeCompilerArgs are
finalized and Gradle doesn't allow further modification.
^KT-27301 In Progress
Old one is deprecated and delegates to new options. All new options
are marked with task input types, so they could be used as `@Nested`
input.
Generated options are using specific types in generated
compiler options. This should simplify code completion and provide
meaningful hints to user.
At this point repository compilation will fail.
^KT-27301 In Progress
To avoid exposing compiler internal types inside Gradle DSL public api.
ApiVersion and LanguageVersion in terms of compiler api is almost the
same. Actually ApiVersion is generated based on LanguageVersion. To
reduce user confusion what enum to use and what is the difference
- in Gradle DSL they are now exposed as single enum - KotlinVersion.
Mark KotlinVersion with DeprecationLevel.ERROR if related
LanguageVersion is unsupported and with DeprecationLevel.WARNING if
related LanguageVersion is deprecated.
^KT-27301 In Progress
Problem: ClasspathChangesComputer (a core component of the new IC) uses
the existing inline function analysis from the old IC
(IncrementalJvmCache.InlineFunctionsMap). If an inline property accessor
has changed, the inline function analysis will report the name of the
property accessor, not the name of the property.
ClasspathChangesComputer doesn't see the property accessor's name in the
list of class/package members, so it will throw an exception.
Solution: There are 2 options:
1. If an inline property accessor has changed, the inline function
analysis can report the name of the property instead of the
property accessor.
2. ClasspathChangesComputer can include property accessors in the list
of class/package members.
In this commit, we will choose option 2 as it is simpler.
Test: New KotlinOnlyClasspathChangesComputerTest.testPropertyAccessors
Small cleanup - PLS SQUASH INTO PREVIOUS COMMIT
- Address review
- Fix failed tests
- Add some trivial changes
^KT-53871 Fixed
Make it clear that there 3 distinct cases:
1. Incremental compilation completed with an ExitCode.
2. Incremental compilation was not possible for some valid reason
(e.g., for a clean build), and we will perform non-incremental
compilation.
3. Incremental compilation failed with an exception.
In this case, we will:
- Print a warning with a stack trace
- Ask the user to file a bug
- Collect rebuild reason enum for analytics
+ TODO: Collect the stack trace too
- Fall back to non-incremental compilation
Test: Existing BaseIncrementalCompilationMultiProjectIT.testFailureHandling_UserError,
Updated BaseIncrementalCompilationMultiProjectIT.testFailureHandling_ToolError
^KT-53015: In progress
Mikhail Glukhikh