Ban "--platforms" from config_setting

[gregestren]

Description of the problem / feature request:

Spawned from this comment thread: https://docs.google.com/a/google.com/document/d/1UZaVcL08wePB41ATZHcxQV4Pu1YfA1RvvWm8FbZHuW8/edit?disco=AAAADQko1J8

We want to discourage select()ing on platforms, in preference for constraint_settings. In other words, it's far preferable to have:

config_setting(
    ...,
    constraint_values = ["@platforms//os:linux"])

than separate config_settings for every specific Linux-based platform definition.

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

Sane, maintainable, generic multi-platform support.

More rationale: https://github.com/hlopko/bazel_platforms_examples/blob/4019120264181e491bc148a5e874e1de55b01f58/examples/05_select_on_platform/README.md

Have you found anything relevant by searching the web?

#8583 - would allow embedding this directly in select (no need for an intermediate config_setting)

[gregestren]

@katre , @hlopko , @aragos for input. I'm happy to implement if it makes sense.

We could take this even farther and ban everything in PlatformOptions.

This is also an opportunity to conservatively roll out platform support + best practices, then relax these restrictions only when/if we see clear need to.

[gregestren]

Also comment from @katre on the original thread:

It would be nice to either forbid it, or at least show an error saying something like "This doesn't work like you think it does". Maybe a similar error for "--host_cpu" and other host flags would also be useful?

[katre]

I like the concept. Ideally it'd be more flexible than just a blacklist in config_setting: possibly a new setting/metadata on individual flags?

[c-parsons]

I like the concept. Ideally it'd be more flexible than just a blacklist in config_setting: possibly a new setting/metadata on individual flags?

+1

I've also had this thought with respect to flags labeled "experimental".

[gregestren]

I like the concept. Ideally it'd be more flexible than just a blacklist in config_setting: possibly a new setting/metadata on individual flags?

Looks like we already have precedent:

bazel/src/main/java/com/google/devtools/build/lib/analysis/config/FragmentOptions.java

Lines 117 to 136 in 4760cc3

	* Returns a map from options defined by this fragment to restrictions on whether the option may
	* appear in a {@code config_setting}. If an option defined by this fragment is not a key of this
	* map, then it has no restriction.
	*
	* <p>In addition to making options unconditionally non-selectable, this can also be used to gate
	* selectability based on the value of other flags in the same fragment -- for instance,
	* experimental or incompatible change flags.
	*
	* <p>The intended usage pattern is to define, for each flag {@code foo} to have a restriction, a
	* field
	*
	* <pre>{@code
	* private static final OptionDefinition FOO_DEFINITION =
	* OptionsParser.getOptionDefinitionByName(ThisClass.class, "foo");
	* }</pre>
	*
	* This way, if the option is ever renamed (especially common for an experimental flag), if the
	* definition is not updated at the same time it will fail-fast during static initialization.
	*/
	public Map<OptionDefinition, SelectRestriction> getSelectRestrictions() {

[gregestren]

While there's a broader theme this highlights, this bug should remain focused specifically on --platforms, as that has its own, and wide-ranging, reasons for exclusion. And it's a smaller practical scope.

I'm going to close this since there's no urgency for this yet and I don't think that's happening soon. We can re-open when/if we sense this is truly something to worry about.