-
Notifications
You must be signed in to change notification settings - Fork 208
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
Bencodes
merged 3 commits into
bazelbuild:master
from
comius:cleanup-legacy-struct-providers
Apr 26, 2024
Merged
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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
There was a problem hiding this comment.
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.There was a problem hiding this comment.
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?There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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