Add detect_scala_info_provider in .bazelproject

[julius-stripe]

Checklist

• I have filed an issue about this change and discussed potential changes with the maintainers.
• I have received the approval from the maintainers to make this change.
• This is not a stylistic, refactoring, or cleanup change.

Please note that the maintainers will not be reviewing this change until all checkboxes are ticked. See
the Contributions section in the README for more
details.

Discussion thread for this change

Issue number: #8182

Description of this change

Adds a new .bazelproject section detect_scala_info_provider to opt into the older heuristic-based scala rule detection

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the configuration options for Scala projects by introducing a new setting in .bazelproject files. This addition provides a mechanism to control the Scala target detection strategy, offering compatibility for projects that might rely on older rules_scala implementations. The change ensures that users can explicitly choose between the modern ScalaInfo provider-based detection and a legacy heuristic approach, thereby improving flexibility without altering the default behavior for current setups.

Highlights

• New .bazelproject section: Introduced a new .bazelproject section named detect_scala_info_provider.
• Scala detection flexibility: This new section allows users to opt into an older heuristic-based Scala rule detection method, which is useful for projects using older rules_scala versions that do not export the ScalaInfo provider.
• Default behavior: By default, the system will continue to use the ScalaInfo provider for Scala target detection.

Changelog

• base/src/com/google/idea/blaze/base/projectview/section/sections/DetectScalaInfoProviderSection.java
  • Added a new Java class to define the detect_scala_info_provider section, including its key and parser.
• base/src/com/google/idea/blaze/base/projectview/section/sections/Sections.java
  • Registered the parser for the newly introduced DetectScalaInfoProviderSection to make it available for project view parsing.
• base/src/com/google/idea/blaze/base/sync/aspects/storage/AspectTemplateWriter.kt
  • Modified the Scala language detection logic to incorporate the value of the detect_scala_info_provider setting, allowing it to influence whether Scala is considered enabled based on the chosen detection method.
• base/tests/unittests/com/google/idea/blaze/base/projectview/ProjectViewSetTest.java
  • Added a test case to verify that the DetectScalaInfoProviderSection is correctly handled during ProjectViewSet serialization and deserialization.

Activity

• The author has filed an issue (Broken scala_info aspect on old rules_scala #8182) and discussed potential changes with maintainers.
• The author has confirmed that this change is not a stylistic, refactoring, or cleanup change, indicating it introduces new functionality.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a new .bazelproject setting, detect_scala_info_provider, which allows users to opt-out of using the ScalaInfo provider for Scala target detection and fall back to an older heuristic-based method. This is useful for projects using older versions of rules_scala.

The changes include:

• A new DetectScalaInfoProviderSection to define the project view setting.
• Integration of this setting into the aspect generation logic in AspectTemplateWriter.
• Updates to the list of supported sections and related tests.

The implementation looks correct and addresses the issue described. I have one suggestion to improve the newly added DetectScalaInfoProviderSection class by making it non-instantiable, which is a common best practice for utility classes.

[gemini-code-assist]

This class only contains static members and is not intended to be instantiated. It's a good practice to make such utility classes final and provide a private constructor to prevent instantiation.

Suggested change

	public class DetectScalaInfoProviderSection {
	public static final SectionKey<Boolean, ScalarSection<Boolean>> KEY =
	SectionKey.of("detect_scala_info_provider");
	public static final SectionParser PARSER = new BooleanSectionParser(
	KEY,
	"""
	Set to false if using an older rules_scala version (e.g. @io_bazel_rules_scala) that \
	does not export ScalaInfo from scala/providers.bzl. When false, Scala targets are \
	detected using the rule-name prefix heuristic (ctx.rule.kind.startswith("scala")) \
	instead of the ScalaInfo provider. By default this is true.
	""");
	}
	public final class DetectScalaInfoProviderSection {
	private DetectScalaInfoProviderSection() {}
	public static final SectionKey<Boolean, ScalarSection<Boolean>> KEY =
	SectionKey.of("detect_scala_info_provider");
	public static final SectionParser PARSER = new BooleanSectionParser(
	KEY,
	"""
	Set to false if using an older rules_scala version (e.g. @io_bazel_rules_scala) that \
	does not export ScalaInfo from scala/providers.bzl. When false, Scala targets are \
	detected using the rule-name prefix heuristic (ctx.rule.kind.startswith("scala")) \
	instead of the ScalaInfo provider. By default this is true.
	""");
	}

[julius-stripe]

I followed the exact pattern in https://github.com/bazelbuild/intellij/blob/ijwb/base/src/com/google/idea/blaze/base/projectview/section/sections/AutomaticallyDeriveTargetsSection.java, not opinionated here, I can follow the suggestion if you would like