Weird behavior with alias and target_compatible_with

[tgeng]

Description of the bug:

Setting target_compatible_with on alias does not work as expected. See repro below.

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

Consider the following top-level BUILD.bazel file. (full repro bazel-alias-bug.zip)

filegroup(
  name = "source",
  srcs = ["foo.c"],
)

alias(
  name = "source_alias",
  actual = "source",
  target_compatible_with = ["@platforms//cpu:x86_64"],
)

alias(
  name = "source_alias2",
  actual = select({
    "@platforms//cpu:x86_64": "source",
    "//conditions:default": "source",
  }),
  target_compatible_with = ["@platforms//cpu:x86_64"],
)

cc_library(
  name = "foo",
  srcs = ["source_alias"],
)

cc_library(
  name = "foo2",
  srcs = ["source_alias2"],
)

foo and foo2 should behave the same. However, on an M1 Mac with Bazel 6.0.0, I have

 ~/tmp/bazel_alias_bug  master ───────────────────────────────────────────────────────────────────── system py  22:39:33
> bazel build :foo
INFO: Analyzed target //:foo (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //:foo up-to-date:
  bazel-bin/libfoo.a
INFO: Elapsed time: 0.081s, Critical Path: 0.00s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action
 ~/tmp/bazel_alias_bug  master ───────────────────────────────────────────────────────────────────── system py  22:39:34
> bazel build :foo2
ERROR: Target //:foo2 is incompatible and cannot be built, but was explicitly requested.
Dependency chain:
    //:foo2 (602a7d)
    //:source_alias2 (602a7d)   <-- target platform (@local_config_platform//:host) didn't satisfy constraint @platforms//cpu:x86_64
INFO: Elapsed time: 0.044s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)

With Bazel 5.4.0, I have

> bazel build :foo
Starting local Bazel server and connecting to it...
ERROR: Target //:foo is incompatible and cannot be built, but was explicitly requested.
Dependency chain:
    //:foo
    //:source_alias   <-- target platform (null) didn't satisfy constraint @platforms//cpu:x86_64
INFO: Elapsed time: 7.002s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (38 packages loaded, 263 targets configured)
 ~/tmp/bazel_alias_bug  master !1 ────────────────────────────────────────────────────────────── 7s  system py  22:40:16
> bazel build :foo2
ERROR: Target //:foo2 is incompatible and cannot be built, but was explicitly requested.
Dependency chain:
    //:foo2
    //:source_alias2   <-- target platform (@local_config_platform//:host) didn't satisfy constraint @platforms//cpu:x86_64
INFO: Elapsed time: 0.088s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 2 targets configured)

Behavior of foo2 is correct in both cases. foo is both incorrect in 5.4.0 and 6.0.0.

Which operating system are you running Bazel on?

macOS

What is the output of bazel info release?

release 5.4.0 and release 6.0.0

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

No response

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

No response

Have you found anything relevant by searching the web?

No response

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

No response

[gregestren]

Assigned to self for triage.

[gregestren]

I can reproduce.

I wonder if this is because the logic doesn't check source files for compatibility, although I'm not sure what makes the select() different.

@philsc for reference.

[gregestren]

Maybe #14096 explains the different in Bazel 6.0?

[philsc]

The difference in 6.0 is indeed caused by the refactor in #14096. I thought I got this working, but apparently it doesn't work for alias without a select().

In particular, the platformInfo is null for the non-select alias():

bazel/src/main/java/com/google/devtools/build/lib/skyframe/PrerequisiteProducer.java

Lines 334 to 335 in c8388e3

	platformInfo =
	unloadedToolchainContexts != null ? unloadedToolchainContexts.getTargetPlatform() : null;

I haven't dug into why, but I'm guessing it has something to do with the fact that we want to be able to create aliases to platform constraints. In which case we don't want to evaluate toolchain information unless necessary.

[philsc]

Okay, piggy backing on @gregestren 's #14310, this patch appears to fix the issue:

diff --git a/src/main/java/com/google/devtools/build/lib/packages/Rule.java b/src/main/java/com/google/devtools/build/lib/packages/Rule.java
index a931906337..d7a9fef42c 100644
--- a/src/main/java/com/google/devtools/build/lib/packages/Rule.java
+++ b/src/main/java/com/google/devtools/build/lib/packages/Rule.java
@@ -1225,8 +1225,10 @@ public class Rule implements Target, DependencyFilter.AttributeInfoProvider {
       return true;
     } else if (mode == ToolchainResolutionMode.HAS_SELECT) {
       RawAttributeMapper attr = RawAttributeMapper.of(this);
-      return (attr.has(RuleClass.CONFIG_SETTING_DEPS_ATTRIBUTE)
-          && !attr.get(RuleClass.CONFIG_SETTING_DEPS_ATTRIBUTE, BuildType.LABEL_LIST).isEmpty());
+      return ((attr.has(RuleClass.CONFIG_SETTING_DEPS_ATTRIBUTE)
+          && !attr.get(RuleClass.CONFIG_SETTING_DEPS_ATTRIBUTE, BuildType.LABEL_LIST).isEmpty()) ||
+          (attr.has(RuleClass.TARGET_COMPATIBLE_WITH_ATTR)
+           && !attr.get(RuleClass.TARGET_COMPATIBLE_WITH_ATTR, BuildType.LABEL_LIST).isEmpty()));
     } else {
       return false;
     }

@gregestren , WDYT about that? It seems fairly innocuous. At least compared to the existing logic.

Happy to rename the HAS_SELECT to something more generic too.

[gregestren]

@philsc that sounds good. Thanks for getting to the bottom of this.

I don't know what the right updated name to HAS_SELECT would be. But conceptually I think it'd be some term expressing "needs toolchain resolution for reasons outside the rules-specific implementation logic".