bazel: incompatible_disallow_struct_provider_syntax: disallow rule implementation functions returning struct

Flag: --incompatible_disallow_struct_provider_syntax Available since: 0.23 (February 2019 release)

Motivation The motivation for this change is described in #6241

Migration Rule implementation functions should return a collection of provider instances instead of a struct

# Before
def _rule_impl(ctx):
    return struct(
        foo_info = struct(foo = ‘foo’),
        bar_info = struct(bar = ‘bar’),
    )

my_rule = rule(implementation = _rule_impl)

# After
FooInfo = provider()
BarInfo = provider()
def _rule_impl(ctx):
    return [FooInfo(foo = ‘foo’), BarInfo(bar = ‘bar’)]

my_rule = rule(implementation = _rule_impl)

One corner case to note is specifying files for coverage. This used to be done with the hardcoded struct field instrumented_files, but should now be done by using coverage_common.instrumented_files_info(). For example:

# Before
def rule_impl(ctx):
    return struct(
        instrumented_files = struct(
            source_attributes = ["srcs"],
            dependency_attributes = ["deps", "image"],
            extensions = ["js"],
        ),
    )

my_rule = rule(implementation = _rule_impl)

# After
def rule_impl(ctx):
    my_coverage_info = coverage_common.instrumented_files_info(
        ctx,
        source_attributes = ["srcs"],
        dependency_attributes = ["deps", "image"],
        extensions = ["js"])
    return [my_coverage_info]

my_rule = rule(implementation = _rule_impl)

About this issue

  • Original URL
  • State: open
  • Created 5 years ago
  • Reactions: 1
  • Comments: 26 (24 by maintainers)

Commits related to this issue

Most upvoted comments

Hello,

Apologies that this issue fell off my radar.

Re: Coverage: https://docs.bazel.build/versions/master/skylark/rules.html#code-coverage-instrumentation You should now be able to use this for modern coverage-related provider.

Re: java_toolchain_alias.bzl: I’ll look into getting this fixed.

Re: incompatible flag, and --all_incompatible_changes, I would suggest you use the workaround you’ve mentioned, --all_incompatible_changes --incompatible_disallow_struct_provider_syntax=false, if you are blocked on the latter flag. It’s not ideal, but we generally don’t have infrastructure for removing --incompatible_ flags from the all_incompatible_changes set. The far better approach here would be to resolve any blockers of incompatible_disallow_struct_provider_syntax.

We’ve had some debate and discussion on the priority of this particular item. We’ve agreed that we will need to introduce another flag to couple with this one to aid in migration, and we plan on introducing this flag before 1.0