Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove legacy struct providers #1157

Merged
merged 3 commits into from
Apr 26, 2024

Conversation

comius
Copy link
Contributor

@comius comius commented Apr 5, 2024

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

@comius
Copy link
Contributor Author

comius commented Apr 5, 2024

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 --incompatible_disallow_struct_provider_syntax

@@ -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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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.

Copy link
Collaborator

Choose a reason for hiding this comment

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

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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

Copy link
Collaborator

Choose a reason for hiding this comment

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

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.

Copy link
Member

Choose a reason for hiding this comment

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

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?

Copy link
Contributor Author

@comius comius Apr 19, 2024

Choose a reason for hiding this comment

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

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)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

bazelbuild/intellij#6394 was merged.

@Bencodes friendly ping

copybara-service bot pushed a commit to bazelbuild/intellij that referenced this pull request Apr 19, 2024
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
copybara-service bot pushed a commit to bazelbuild/intellij that referenced this pull request Apr 19, 2024
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
copybara-service bot pushed a commit to bazelbuild/intellij that referenced this pull request Apr 23, 2024
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
copybara-service bot pushed a commit to bazelbuild/intellij that referenced this pull request Apr 23, 2024
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
@comius comius requested a review from Bencodes April 25, 2024 10:24
@Bencodes Bencodes merged commit b33a1cc into bazelbuild:master Apr 26, 2024
2 checks passed
mai93 pushed a commit to bazelbuild/intellij that referenced this pull request May 6, 2024
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)
restingbull pushed a commit that referenced this pull request May 31, 2024
* Remove legacy struct providers in main repo

* Change _toolchain to provide Kotlin toolchain info

* Add back original _toolchain and use _kt_toolchain for Kotlin
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.

3 participants