Provide ability to directly select() on constraint_value

[gregestren]

Description of the problem / feature request:

A common and annoyingly redundant pattern is:

constraint_value(
    name = "my_value",
    constraint_setting = "my_setting")

config_setting(
    name = "my_value_selectable",
    constraint_values = [":my_value"])

some_rule(
    ...,
    attr = select({
        ":my_value_selectable": ...
    })

It would be nice to be able to just write:

some_rule(
    ...,
    attr = select({
        ":my_value": ...
    })

Feature requests: what underlying problem are you trying to solve with this feature?

Unnecessary bloat for situations where config_setting is just abstraction overhead.

Have you found anything relevant by searching the web?

Examples:

• https://github.com/bazelbuild/rules_rust/blob/5ec0b832d6a7a7ad183cfb9fb99ff2cf91429caa/rust/platform/platform.bzl#L59-L67
• https://github.com/bazelbuild/rules_dotnet/blob/07ee724341d5bd70e41c6980ee202a282ccb3462/dotnet/platform/list.bzl#L77-L82

Also see #7668 and bazelbuild/bazel-skylib#89 (comment).

[gregestren]

@katre I tried mocking up an implementation of this since it's conceptually at least easy (and select was always designed to support rules beside config_setting).

Some challenges that arose that I appreciate your perspective on:

1. config_setting implements

   bazel/src/main/java/com/google/devtools/build/lib/packages/RuleClass.java

   Lines 1389 to 1393 in af53a11

   	/**
   	* Rules that support platforms can use toolchains and execution platforms. Rules that are part
   	* of configuring toolchains and platforms should set this to {@code false}.
   	*/
   	public Builder supportsPlatforms(boolean flag) {

   which is necessary for it to always invoke toolchain resolution so there are actual target constraint_values to compare against. The constraint_value rule doesn't do that though. What options do we have here?

2. What configuration do constraint_value rules evaluate in today? If in a select would they properly use the same configuration of the rule with the select in it?

3. If this change involves evaluating constraint_value in more configurations, would that bloat the build graph? Or maybe just do this only in the context of a select? Maybe some secret alias rule that secretly sets a requires platforms just for this call option in PlatformOptions that constraint_value can specially consume?

[gregestren]

@hlopko

[katre]

1. The supportsPlatforms method is badly named (and if I ever think of a better one, I will). It's intended to allow rules to opt out of toolchain resolution, because those rules are themselves used in toolchain resolution (in this case, toolchain resolution loads platforms, which the load constraint values). If constraint_value needs to access the current platform in order to correctly provide the matching provider, I think that will work, as long as it is using the target platform, not expecting a valid execution platform.

2. Correct, the configuration is maintained. Someday I want to get rid of it, but we could just make it optional (and if there's no config, a false matching provider is returned?).

3. Every (mostly) configured target already loads platforms and constraint values, so there shouldn't be a huge increase. Worth monitoring, however.

[gregestren]

Promising, thanks! I'll try to whip this up into a proper PR in my spare time.

[hlopko]

CC @jayconrod who wanted this too :)

[gregestren]

Welp, I successfully prototyped this.

Went down a different path than above. I put the platform-retrieving logic in the target that owns the select(), not in the constraint_value. Putting it directly in constraint_value creates a dependency in that resolving the platform requires resolving its constraints.

I'm interested to explore this in review.