Skip to content

Conversation

@mvicsokolova
Copy link
Collaborator

No description provided.

mvicsokolova and others added 4 commits April 21, 2023 15:39
In addition to removal of JS/Legacy configurations, JS compiler type should also be changed from BOTH to IR when switching to Kotlin 1.9.
The removal condition is also based on Kotlin language version now instead of compiler release version (it allows to adopt newer compiler releases without removing JS/Legacy until language version is changed to 1.9+).
This test only fails during testing of Kotlin compiler dev builds at the moment, and thus should probably be muted in `kotlin-community`-branches instead of `develop`.
// (right now it implements a toggle between IR and BOTH JS compiler types for testing of Kotlin dev builds)
def fromVersion = { String arg -> KotlinVersion.values().find { it.version == arg } }
def kotlinLanguageVersion = fromVersion(KotlinAggregateBuild.getOverriddenKotlinLanguageVersion(project) ?: "1.4")
def isJsLegacyCompilerEnabled = kotlinLanguageVersion < KotlinVersion.KOTLIN_1_9
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LanguageVersion has nothing with JS target deprecation. Should be checked using KGP version.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made these changes based on the fact that CLI-level deprecation of JS/Legacy seems to work based on the language version at the moment, so we might want to take a closer look at it in the compiler as well then.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm 👀
For now I rolled this back to KGP version check

Comment on lines 94 to 99
def kotlinVersion = ext.kotlin_version.split('\\.').take(2).collect { it.toInteger() }
if (kotlinVersion[0] == 1 && kotlinVersion[1] == 9) {
test {
exclude "**/JsLegacyTransformationTest*", "**/MppLegacyTransformationTest*"
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would propose to move kotlin version parsing into a method inside buildSrc module. So it could be used in all build files.

if (it instanceof IvyArtifactRepository) {
metadataSources {
artifact()
tasks.withType(compileJsLegacy.getClass()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • compileJsLegacy should be already a Class.
  • after .withType .configureEach { ... } should be used

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With gradle 6.8.3 compilation fails if I remove getClass()

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean in the lines above it could be:

    def compileJsLegacy = tasks.hasProperty("compileKotlinJsLegacy")
            ? compileKotlinJsLegacy.getClass()
            : compileKotlinJs.getClass()

}
}

internal fun isKotlinVersionAtLeast(project: Project, atLeastMajor: Int, atLeastMinor: Int): Boolean =
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably it should be moved to another file

@FenstonSingel
Copy link
Contributor

I've tried compiling this branch with Kotlin 1.9.0-dev-6688 and various LVs. The results are:

  • for LV 1.4 (project LV), only one test fails (it is tracked by JVM legacy transformation: both original and transformed classes stay in the test classpath #295 and is muted in relevant TC configurations)
  • for LV 1.9, the results are the same as for LV 1.4
  • for LV 2.0, tests for post-compilation JVM transformers (transformedTestXX) fail (it should be fixed when the next kotlinx.metadata release is published and migrated to) and 11 out of 11 completed atomicfu-gradle-plugin tests fail (they are muted in relevant TC configurations so I haven't taken a closer look)

From testing of Kotlin dev-builds's perspective, everything is great for 1.9.0-dev TC configurations and good enough for K2 TC configurations (we will probably mute all tests in relevant TC configurations eventually regardless, so red tests are not a big problem).

@mvicsokolova
Copy link
Collaborator Author

Thank you!

I'll have a look what is wrong with atomicfu-gradle-plugin tests for lv=2.0

@mvicsokolova
Copy link
Collaborator Author

@FenstonSingel Am I right, that we can merge these change into develop now? And for dev-builds you will be able to mute failing tests for now?

@mvicsokolova mvicsokolova force-pushed the remove-js-legacy-tweaked branch from 23db8f0 to b831000 Compare April 26, 2023 11:01
* moved check function to buildsrc
@mvicsokolova mvicsokolova force-pushed the remove-js-legacy-tweaked branch from b831000 to 6966e9d Compare April 26, 2023 11:06
@mvicsokolova mvicsokolova requested a review from Tapchicoma April 26, 2023 11:06
@mvicsokolova
Copy link
Collaborator Author

I can locally reproduce the failure of atomicfu-gradle-plugin tests with lv = 1.9. They fail with Could not initialize class kotlinx.atomicfu.plugin.gradle.Platform. Probably that is somehow related to EnumEntries (e.g. KT-57317).

@FenstonSingel
Copy link
Contributor

@FenstonSingel Am I right, that we can merge these change into develop now? And for dev-builds you will be able to mute failing tests for now?

Yes, any failing tests are not a blocker for dev-builds testing.

@mvicsokolova mvicsokolova merged commit 4dd0a6c into develop Apr 26, 2023
@mvicsokolova mvicsokolova deleted the remove-js-legacy-tweaked branch April 26, 2023 13:52
PavelPunegov pushed a commit that referenced this pull request Aug 7, 2023
* JS Legacy build configurations as well as JS Legacy test projects were conditionally removed for KGP version >= 1.9.0

Co-authored-by: Stanislav Ruban <[email protected]>

(cherry picked from commit 4dd0a6c)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants