Remove legacy struct providers #1157
Conversation
comius
requested review from
ahumesky,
cgruber,
restingbull,
Bencodes and
nkoroste
as code owners
|
This is not yet complete cleanup, because rules_kotlin depend on an old release containing .bzl code. To do the full cleanup, this needs to be released, version repinned and then released again. The change was tested by running tests with |
| @@ -41,25 +41,22 @@ def _make_providers(ctx, providers, transitive_files = depset(order = "default") | |||
| files = [ctx.outputs.jar] | |||
| if providers.java.outputs.jdeps: | |||
| files.append(providers.java.outputs.jdeps) | |||
| return struct( | |||
| kt = providers.kt, | |||
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
You're correct, this would cause issues to IntelliJ integration. Struct providers have been deprecated for a long time, and this is one of the very last uses that I detected on Bazel downstream tests. (There are other failures, but mostly due to the use of old versions of other dependencies).
IntelliJ aspect was also until recently using a struct provider for Android rules, that was removed recently. I'll procure a fix for IntelliJ/Kotlin integration. Do you think we should block this PR until that is released?
I'd really like to flip the flag in Bazel @Head to disable struct providers and we're now in the tail of the tail of cleaning up the uses.
There was a problem hiding this comment.
IntelliJ aspect was also until recently using a struct provider for Android rules, that was removed recently. I'll procure a fix for IntelliJ/Kotlin integration. Do you think we should block this PR until that is released?
I'm all for merging this as long as there is a plan in place to fix the Intellij side that they are bought into merging. It would be unfortunate if we drop the struct here and then the Intellij team doesn't merge a similar fix, leaving Kotlin users in limbo.
There was a problem hiding this comment.
There's another problem. I started looking how to fix Intellij. rules_kotlin is using KtJvmInfo here. However, the provider is only exposed through @rules_kotlin//kotlin/internal:defs.bzl. Is it ok to depend on that in IntelliJ, or should we first move it to a more public location?
I also wonder why couldn't IntelliJ use just JavaInfo provider. It seems that there's less information in there than in KtJvmInfo (bazelbuild/intellij#1202). But using JavaInfo would mean nothing needs to be changed in IntelliJ. Maybe we can put more information there?
cc @jin
There was a problem hiding this comment.
There might be some logic that depends on knowing that a target is a "kotlin" in order to enable some Kotlin specific features inside Intellij. I believe this is also the case for Android targets.
If that's not true then in theory it should be fine to just check that final JavaInfo provider. I'd defer to the Intellij team for these questions though since they wrote and maintain the Kotlin integration in the aswb/ijwb plugins.
There was a problem hiding this comment.
It's been a while since I looked at this, so memory's bit hazy.
Just by skimming the code, ISTM that as long as we can provide IntelliJ here with a "marker provider" about a target's Kotlin-ness, then consolidate on JavaInfo on everything else, things should continue to work?
There was a problem hiding this comment.
Ok, what I figured out is that JavaInfo already provides all the information needed. This was done through the years with improvements to Java compilation process. (Change that made it seems to be 2be75c0)
For the toolchains part, a way to expose it to IntelliJ is via _kt_toolchain attribute, which provides language information. We are doing almost the same thing internally.
To support reading in IntelliJ I prepared:
bazelbuild/intellij#6394
(the IntelliJ plugin CI is ATM broken because of a different change)
There was a problem hiding this comment.
bazelbuild/intellij#6394 was merged.
@Bencodes friendly ping
This is a prerequisite to finally turn down legacy struct providers. The last such instance is used in rules_kotlin. And it's used to serve as integration with IntelliJ. After this change, PR bazelbuild/rules_kotlin#1157 may be merged, keeping rules_kotlin working with IntelliJ. Legacy struct providers have been deprecated by Bazel. Replacing them with modern providers, will make it possible to simplify and remove legacy handling from Bazel. More info on: https://bazel.build/extending/rules#migrating_from_legacy_providers Issue: bazelbuild/bazel#19467 PiperOrigin-RevId: 626344394
This is a prerequisite to finally turn down legacy struct providers. The last such instance is used in rules_kotlin. And it's used to serve as integration with IntelliJ. After this change, PR bazelbuild/rules_kotlin#1157 may be merged, keeping rules_kotlin working with IntelliJ. Legacy struct providers have been deprecated by Bazel. Replacing them with modern providers, will make it possible to simplify and remove legacy handling from Bazel. More info on: https://bazel.build/extending/rules#migrating_from_legacy_providers Issue: bazelbuild/bazel#19467 PiperOrigin-RevId: 626344394
This is a prerequisite to finally turn down legacy struct providers. The last such instance is used in rules_kotlin. And it's used to serve as integration with IntelliJ. After this change, PR bazelbuild/rules_kotlin#1157 may be merged, keeping rules_kotlin working with IntelliJ. Legacy struct providers have been deprecated by Bazel. Replacing them with modern providers, will make it possible to simplify and remove legacy handling from Bazel. More info on: https://bazel.build/extending/rules#migrating_from_legacy_providers Issue: bazelbuild/bazel#19467 PiperOrigin-RevId: 626344394
This is a prerequisite to finally turn down legacy struct providers. The last such instance is used in rules_kotlin. And it's used to serve as integration with IntelliJ. After this change, PR bazelbuild/rules_kotlin#1157 may be merged, keeping rules_kotlin working with IntelliJ. Legacy struct providers have been deprecated by Bazel. Replacing them with modern providers, will make it possible to simplify and remove legacy handling from Bazel. More info on: https://bazel.build/extending/rules#migrating_from_legacy_providers Issue: bazelbuild/bazel#19467 PiperOrigin-RevId: 627353414
This is a prerequisite to finally turn down legacy struct providers. The last such instance is used in rules_kotlin. And it's used to serve as integration with IntelliJ. After this change, PR bazelbuild/rules_kotlin#1157 may be merged, keeping rules_kotlin working with IntelliJ. Legacy struct providers have been deprecated by Bazel. Replacing them with modern providers, will make it possible to simplify and remove legacy handling from Bazel. More info on: https://bazel.build/extending/rules#migrating_from_legacy_providers Issue: bazelbuild/bazel#19467 (cherry picked from commit 702227e)
* Remove legacy struct providers in main repo * Change _toolchain to provide Kotlin toolchain info * Add back original _toolchain and use _kt_toolchain for Kotlin
Legacy struct providers have been deprecated by Bazel. Replacing them with modern providers, will make it possible to simplify and remove legacy handling from Bazel.
More info on: https://bazel.build/extending/rules#migrating_from_legacy_providers
Issue: bazelbuild/bazel#19467