Bazel 4.1 fails to desugar kotlinx-coroutines-core-jvm:1.5.0 #13553
Labels
P2
We'll consider working on this in future. (Assignee optional)
team-Android
Issues for Android team
type: bug
Comments
|
Tested against HEAD and it also fails |
|
This issue appears to be a blocker for adopting Jetpack Compose in Bazel projects. (The latest 1.0.0-beta08 release requires Kotlin 1.5.10 and Kotlin coroutines 1.5.0). |
|
Could be caused by Kotlin/kotlinx.coroutines@b400b02 Since AgentPremain contains Wonder how gradle handle |
|
A related issue occurred in Kotlin/kotlinx.coroutines#2046. The workaround there was to make proguard not spew typenotfound errors like so. This case seems to be different - the desugarer blows up, not proguard, but it may be a clue on the hunt. I know we ran into inconsistencies between the bazel desugarer and the desugaring in the android toolchain, and in some cases resolved things by calling out to d8 in a custom toolchain, but it's not clear whether the problems we had were connected to this one. I know gradle uses d8's desugaring, and may simply have special case logic around sun.misc stuff, which I think gets magically swapped by Android's jvm impl anyway (or things that rely on it are swizzled in) |
|
The original report seems to indicate that desugaring is run on JDK11. Does this also happen when using a JDK8 as host JDK? |
|
I just tried with a JDK8: And got what looks like the exact same stacktrace: Interestingly enough, I had to use |
|
The second error suggests that kotlin-stdlib.jar isn't on the classpath of kotlinx-coroutines-core-jvm-1.5.0.jar. You may need to add the former as a dep to the import of the latter. Could you also possibly share the output you get from including |
Wouldn't
This is what I get for the And not much more for the continuation related one: |
Note the missing Thanks for the |
This is what i'm seeing in the param file for ❯ cat bazel-out/android-armeabi-v7a-fastbuild/bin/external/maven/_dx/org_jetbrains_kotlinx_kotlinx_coroutines_core_jvm/kotlinx-coroutines-core-jvm-1.5.0.jar_desugared.jar-0.params
--input
external/maven/v1/https/repo1.maven.org/maven2/org/jetbrains/kotlinx/kotlinx-coroutines-core-jvm/1.5.0/kotlinx-coroutines-core-jvm-1.5.0.jar
--output
bazel-out/android-armeabi-v7a-fastbuild/bin/external/maven/_dx/org_jetbrains_kotlinx_kotlinx_coroutines_core_jvm/kotlinx-coroutines-core-jvm-1.5.0.jar_desugared.jar
--classpath_entry
bazel-out/android-armeabi-v7a-fastbuild/bin/external/maven/v1/https/repo1.maven.org/maven2/org/jetbrains/kotlinx/kotlinx-coroutines-core-jvm/1.5.0/header_kotlinx-coroutines-core-jvm-1.5.0.jar
--classpath_entry
bazel-out/android-armeabi-v7a-fastbuild/bin/external/maven/v1/https/repo1.maven.org/maven2/org/jetbrains/kotlin/kotlin-stdlib-common/1.5.0/header_kotlin-stdlib-common-1.5.0.jar
--classpath_entry
bazel-out/android-armeabi-v7a-fastbuild/bin/external/maven/v1/https/repo1.maven.org/maven2/org/jetbrains/kotlin/kotlin-stdlib-jdk8/1.5.0/header_kotlin-stdlib-jdk8-1.5.0.jar
--classpath_entry
bazel-out/android-armeabi-v7a-fastbuild/bin/external/maven/v1/https/repo1.maven.org/maven2/org/jetbrains/kotlin/kotlin-stdlib/1.5.0/header_kotlin-stdlib-1.5.0.jar
--classpath_entry
bazel-out/android-armeabi-v7a-fastbuild/bin/external/maven/v1/https/repo1.maven.org/maven2/org/jetbrains/annotations/13.0/header_annotations-13.0.jar
--classpath_entry
bazel-out/android-armeabi-v7a-fastbuild/bin/external/maven/v1/https/repo1.maven.org/maven2/org/jetbrains/kotlin/kotlin-stdlib-jdk7/1.5.0/header_kotlin-stdlib-jdk7-1.5.0.jar
--bootclasspath_entry
external/androidsdk/platforms/android-29/android.jar
--emit_dependency_metadata_as_needed |
|
Aha thanks. It's possible that |
ahumesky
added
the
P2
|
Is there way to workaround the issue? Can we add |
|
Bencodes/bazel_issue_13553#1 is a working workaround. |
Thanks a lot! |
|
Reproduced on release 5.2.0 |
6 tasks
adhiamboperes
added a commit
to oppia/oppia-android
that referenced
this issue
Jun 12, 2024
## Explanation Fixes #4119 Fixes #4120 Fixes part of #59 This PR finishes the migration of the codebase to Kotlin 1.6 (addressing both #4119 and #4120). Kotlin 1.6 is needed as part of moving rules_kotlin to 1.7.x (which is, in turn, needed in conjunction with Bazel 6.x to enable strict dependency checking which significantly simplifies modularization which is planned for downstream PRs). This PR doesn't actually finish the movement to that version of rules_kotlin, but it does finish moving the codebase to a new enough (and no longer pre-release) version of rules_kotlin to allow using Kotlin 1.6 (over Kotlin 1.4 that the codebase currently uses): version 1.5.0. Previous PRs (#5400 and #5402) prepared for the changes here by addressing large categories of build warnings that have either arisen from this migration, or from past work. Note that another large category of warnings have also been addressed in this PR: by moving to Kotlin 1.6, there's no longer a runtime incompatibility between the Kotlin SDK and the reflection APIs (which was causing a _lot_ of warning output previously). Between all three PRs, the output is now very clean and free of nearly all build warnings. To try and keep the warnings clean long-term, this PR introduces warnings-as-errors for both Java and Kotlin code. However, please note some caveats: - Dagger generated code doesn't follow the Java warnings-as-error flag, so those warnings were cleaned up manually (and will need to be generally watched for, unfortunately). - The version of rules_kotlin used in this PR doesn't directly support turning on the functionality, but does internally (so a small patch file has been added to augment rules_kotlin). When the codebase is updated to rules_kotlin 1.7.x this patch will no longer be needed. - To ease development, a build configuration flag was added to disable failure upon encountering build warnings (per https://bazel.build/run/bazelrc and https://bazel.build/docs/configurable-attributes#query-and-cquery as an example), though this needs to be opted into: ```sh bazel build --config=ignore_build_warnings <target> ``` Some other details to note: - Version 1.6.10 is specifically picked in order to ensure Jetpack Compose compatibility (for preparation of the work being prototyped in #5401 to be compatible with the Oppia Android build environment). - The vast majority of code in this PR is updating parameterized tests to use a cleaner repeatable annotation pattern that wasn't available in Kotlin 1.4. - This upgrade absolutely does have runtime implications, but we're relying very heavily on existing automated tests to ensure correctness and no regressions. - This PR doesn't make an effort to move toward newer Kotlin language features except where forced (API deprecations) or largely wanted (the repeatable annotation change). - android-spotlight and kotlitex have been updated to support newer versions of Kotlin (as both are custom forks managed in the broader Oppia GitHub organization). - Gradle files have been updated to match the same dependency versions as Bazel (where it was obvious to make changes; some might still be a bit off). - The Gradle build configuration was also updated to use Kotlin 1.6.x (otherwise there would be build incompatibilities with Bazel). I think this is the last upgrade we can do for Gradle without upgrading AGP (which will cause us significant issues with the model module, so we're planning on instead dropping Gradle support). - API changes that needed to be addressed in this PR due to deprecations include: ``String.captialize``, ``String.toLowerCase``, ``String.toUpperCase``, ``SendChannel.offer``, and ``Char.toInt``. - New API changes that have been leveraged in this PR: ``Flow.lastOrNull`` and ``Deferred.asListenableFuture`` (to replace ``SettableFuture`` for safety; this also resulted in nice simplifications in ``CoroutineExecutorService``). - The JVM coroutines dependency needed to be split out from Maven and manually imported with some empty internal Java class files since it otherwise has some issues being desugared: bazelbuild/bazel#13553. This is a problem with the Desugarer used in Bazel 4.x (and maybe later versions, so this solution will probably need to kept for a while). - Some Proguard rule updates were needed due to Kotlin SDK changes--see the Proguard file & comments for specifics. - Due to dependency changes, the KitKat main dex file was also trimmed down. I'm fairly certain that it's already crashing on startup, so I don't care much about this change--it just needs to build. We plan to remove KitKat entirely eventually, anyway: #5012. - Jetifier (that is, automatic conversion from support libraries to Jetpack/AndroidX) support was disabled in Gradle. We don't have it enabled in Bazel, and it could potentially encourage strange one-version violations if it was ever actually needed. This is a safer (and likely more performant) change to make. - Moshi was updated to 1.13 to support the upgrade in Kotlin. This did result in a small configuration change due to its annotation processor being moved. Note that Moshi 1.14 couldn't be supported since it requires Kotlin 1.7+ which requires rules_kotlin 1.7+. This will be an option to upgrade in the future. - Some improvements and fixes were made in ``FilterPerLanguageResources`` (I think it was outputting something incorrectly before and that's now been fixed as part of a broader logical reworking of the filtering logic). - ``com.android.support:support-annotation`` was removed as a dependency since it was never used in Bazel, and shouldn't be used (since it's support library and not AndroidX). - The updates to Moshi and Kotlin dependencies resulted in a bunch of other transitive dependency updates. - Note that Gradle doesn't have ``allWarningsAsErrors`` enabled since it would require fixing more warnings than is exposed in Bazel, and we're using Bazel builds as the general source of truth for code quality. ## Essential Checklist - [x] The PR title and explanation each start with "Fix #bugnum: " (If this PR fixes part of an issue, prefix the title with "Fix part of #bugnum: ...".) - [x] Any changes to [scripts/assets](https://github.com/oppia/oppia-android/tree/develop/scripts/assets) files have their rationale included in the PR explanation. - [x] The PR follows the [style guide](https://github.com/oppia/oppia-android/wiki/Coding-style-guide). - [x] The PR does not contain any unnecessary code changes from Android Studio ([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#undo-unnecessary-changes)). - [x] The PR is made from a branch that's **not** called "develop" and is up-to-date with "develop". - [x] The PR is **assigned** to the appropriate reviewers ([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#clarification-regarding-assignees-and-reviewers-section)). ## For UI-specific PRs only N/A -- This is an infrastructural change. While it could inadvertently affect user-facing code, it shouldn't based on the current passing state of automated tests. --------- Co-authored-by: Adhiambo Peres <[email protected]> Co-authored-by: Sean Lip <[email protected]>
|
Is this still an issue with the D8-based desugarer, or with the starlark android rules? We can reopen and transfer to rules_android if so |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of the problem / feature request:
Bazel 4.1 fails to desugar
kotlinx-coroutines-core-jvm:1.5.0producing the following exception:Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Steps to reproduce can be found here https://github.com/Bencodes/bazel_issue_13553
Example failure: https://github.com/Bencodes/bazel_issue_13553/runs/2742154274?check_suite_focus=true#step:5:44
What operating system are you running Bazel on?
macOs 10.15.7
What's the output of
bazel info release?release 4.1.0
Any other information, logs, or outputs that you want to share?
java-runtime: OpenJDK Runtime Environment (build 11.0.6+10-LTS) by Azul Systems, Inc.
java-vm: OpenJDK 64-Bit Server VM (build 11.0.6+10-LTS, mixed mode) by Azul Systems, Inc.
The text was updated successfully, but these errors were encountered: