Using `--cpu=darwin_x86_64` in `platform_mappings` triggers unnecessary toolchain evaluation

Description of the bug:

This is a follow-up to #12897. The fix (#14096) doesn’t address the original problem when platform_mappings is in use. When not using platform_mappings, there is no problem.

What’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

The objective is to prevent bazel from analysing objc_library targets on Linux.

Create this BUILD file:

objc_library(
    name = "objc",
    target_compatible_with = [
        "@platforms//os:macos",
    ],
)

platform(
    name = "macos",
    constraint_values = [
        "@platforms//os:macos",
    ],
)

The target is appropriately skipped on a Linux machine:

$ bazel build //:all
INFO: Analyzed target //:objc (0 packages loaded, 117 targets configured).
INFO: Found 1 target...
Target //:objc was skipped
INFO: Elapsed time: 0.481s, Critical Path: 0.04s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action

Now add a platform_mappings file:

platforms:
  //:macos
    --cpu=darwin_x86_64

flags:
  --cpu=darwin_x86_64
    //:macos

and you see the same error originally reported in #12897:

$ bazel build --platform_mappings=platform_mappings //:all
ERROR: /bazel-cache/phil/bazel/_bazel_phil/8299a41ccdd1478ccc4dfad80faab3e8/external/local_config_cc/BUILD:47:19: in cc_toolchain_suite rule @local_config_cc//:toolchain: cc_toolchain_suite '@local_config_cc//:toolchain' does not contain a toolchain for cpu 'darwin_x86_64'
ERROR: /bazel-cache/phil/bazel/_bazel_phil/8299a41ccdd1478ccc4dfad80faab3e8/external/local_config_cc/BUILD:47:19: Analysis of target '@local_config_cc//:toolchain' failed
ERROR: Analysis of target '//:objc' failed; build aborted: 
INFO: Elapsed time: 0.232s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 258 targets configured)

It’s worth noting that this only happens with --cpu=darwin_x86_64. If I instead add a --cpu=k8 platform mapping, then the error goes away again.

Which operating system are you running Bazel on?

x86_64 Debian 11

What is the output of bazel info release?

development version

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

$ git log --oneline -1
61c433e896 (HEAD, upstream/master) Content clarifications and markdown fixes for consistency with other tutorials.
$ git status
HEAD detached at upstream/master
nothing to commit, working tree clean
$ bazel build -c opt //src:bazel-bin

What’s the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

$ git remote get-url upstream
https://github.com/bazelbuild/bazel
$ git rev-parse HEAD
61c433e8968549781664194b9c046335f125c07a

Have you found anything relevant by searching the web?

N/A

Any other information, logs, or outputs that you want to share?

I will investigate possible solutions to this.

[philsc]

Perhaps a related question is: What’s the motivation behind objc_library performing this transition? Seems like it’s making a decision that users should be making. I.e. I would imagine, all use cases of objc_library can still be satisfied without this self-transition.

[gregestren]

Yes, that makes sense @pcjanzen (and I hope that addresses your confusion @philsc about why objc_library targets a different platform than you intended - it’s set in a transition).

I understand your use case. Thanks for detailing it out. The challenge with this bug is that all pieces of functionality are working as intended. It’s not a bug, per se. But you’re showing how that can still produce a bad user experience.

Core configurability devs will review this this week as part of routine bug triage. Let’s get another update from that review.