Transitions can inspect configurable attributes, but don't see a value for them

[illicitonion]

Description of the problem / feature request:

When a rule has a configurable attribute, a transition which operates on the rule gets an attr map which doesn't contain the attr name or value at all.

This can cause buggy behaviour. e.g. this transition in rules_go looks at what the value of getattr(attr, "static", "auto") to decide whether to statically link a binary, but if the static attribute is a configurable attribute, the transition will always see None as the value of the attribute, so will fall back to its default behaviour.

Ideally the transition would get the current configuration's value of the attribute.

If that's not feasible, trying to read one of these attributes in a configuration should be an error (conceptually, we'd be declaring any attribute used in a transition as non-configurable, but by doing this detection on the fly and raising a runtime error; alternatively, we could introduce a "non-configurable" marker on attrs, and require it to be set for any attributes read by transitions).

In the case we decide to forbid this acces, it would be great to work out how rules_go's transition should be determining whether a target should be compiled as static.

Either way, silently hiding the attribute is error-prone.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

% touch WORKSPACE
% cat >rules.bzl <<EOF
def _print_transition_impl(settings, attr):
    print("Attr: {}".format(getattr(attr, "explicit_config", "NOT PRESENT")))
    return {}

print_transition = transition(
    implementation = _print_transition_impl,
    inputs = ["//command_line_option:cpu"],
    outputs = ["//command_line_option:compilation_mode"],
)

def _is_transitioned_impl(ctx):
    out = ctx.actions.declare_file(ctx.label.name)
    ctx.actions.write(
        output = out,
        content = ctx.attr.explicit_config,
    )
    return [DefaultInfo(files=depset([out]))]

is_transitioned = rule(
    implementation = _is_transitioned_impl,
    attrs = {
        "explicit_config": attr.string(default = "one"),
        "_whitelist_function_transition": attr.label(default = "@bazel_tools//tools/whitelists/function_transition_whitelist"),
    },
    cfg = print_transition,
)
EOF
% cat >BUILD.bazel <<EOF
load("//:rules.bzl", "is_transitioned")

is_transitioned(
    name = "transitioned",
    # This version shows up in the transition:
    #explicit_config = "String in BUILD",
    # This version does not:
    explicit_config = select({"//conditions:default": "Default condition in BUILD"}),
)
EOF
% bazel build :transitioned

Expect to see printed "Attr: Default condition in BUILD"
Actually see printed: "Attr: NOT PRESENT"

If you switch over the commented explicit_config values in the BUILD.bazel file and re-run, you'll see "Attr: String in BUILD" as expected.

What operating system are you running Bazel on?

macOS

What's the output of bazel info release?

release 6.0.0-pre.20220324.1

[illicitonion]

/cc @gregestren

[gregestren]

Just skimming this (apologies!), but I think this is an intentional design restriction described at https://bazel.build/rules/config#defining. Specifically:

When attached as an incoming edge transition, attr does not include any attributes that use a selector to resolve their value. If an incoming edge transition on --foo reads attribute bar and then also selects on --foo to set attribute bar, then there's a chance for the incoming edge transition to read the wrong value of bar in the transition.

https://docs.google.com/document/d/1VIRx06cZB4wLU-ASq1XKFHmx67yfHtNOCbCempaPeaA/ gets into the ugly details:

In order to make the second change work, we need to introduce restrictions for starlark rules that use parameterized rule class transitions. Parameterized rule class transitions cannot depend on attribute values that proceed to depend on configuration (i.e. through a select) since this would introduce a configuration->attribute->configuration dependency cycle.

To deal with this, we’ll throw runtime errors for transition implementation functions that create these dependency cycles. The specific case we’re interested in is when (1) a build setting* is declared written by a transition at any point** on the incoming edge to a rule-transitioned target, (2) an incoming rule transition transition reads an attribute of the target, and (3) that target configures the same attribute using the same build setting. If this happens, we’ll throw an error when we try to access that attribute in the transition implementation function. This all gets a bit hairy, see the examples below for a more concrete example.

I agree that silent failure is no good. It looks like the original intention was for Bazel to communicate the problem?

Also, I think the main conclusion from then was that supporting your use case is technically hard. That doesn't necessarily mean it's impossible - there may be some innovative thinking we didn't think of. The current state is largely a desire to get the functionality working and aiming for just not supporting certain use cases vs. blocking the functionality on a more complete solution. I'm open to creative ideas beside better error messaging if you can think of any.