Toolchain resolution stumbles over workspace prefixes in constraint labels

[aherrmann]

Description of the problem:

Bazel fails to resolve a toolchain if one of the constraint_values entries of the current platform is defined without a workspace prefix, while the exec_compatible_with of the toolchain uses the same constraint but with a workspace prefix. E.g. in rules_nixpkgs we define the constraint and platform in nixpkgs/constraints/BUILD.bazel as

constraint_value(
    name = "nixpkgs",
    constraint_setting = "@bazel_tools//tools/cpp:cc_compiler",
    visibility = ["//visibility:public"],
)

platform(
    name = "linux_x86_64_nixpkgs",
    constraint_values = [
        "@platforms//cpu:x86_64",
        "@platforms//os:linux",
        ":nixpkgs",
    ],
    visibility = ["//visibility:public"],
)

Note the constraint_values entry :nixpkgs without workspace prefix.

But in the toolchain we use

toolchain(
    name = "toolchain",
    toolchain = ":py_runtime_pair",
    toolchain_type = "@bazel_tools//tools/python:toolchain_type",
    exec_compatible_with = [
        "@platforms//cpu:x86_64",
        "@platforms//os:{os}",
        "@io_tweag_rules_nixpkgs//nixpkgs/constraints:nixpkgs",
    ],
    target_compatible_with = [
        "@platforms//cpu:x86_64",
        "@platforms//os:{os}",
    ],
)

Note the fully qualified constraint @io_tweag_rules_nixpkgs//nixpkgs/constraints:nixpkgs.

The WORKSPACE file does specify workspace(name = "io_tweag_rules_nixpkgs"), so those labels indicate the same constraint.

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

Checkout tweag/rules_nixpkgs@a897d1a and execute the following command

nix-shell --pure --run 'bazel test //tests:python-test --toolchain_resolution_debug'

The test should fail and the log should contain the following lines

INFO: ToolchainResolution: Looking for toolchain of type @bazel_tools//tools/python:toolchain_type...
INFO: ToolchainResolution:   Considering toolchain @nixpkgs_python_toolchain//:py_runtime_pair...
INFO: ToolchainResolution:     Toolchain constraint @bazel_tools//tools/cpp:cc_compiler has value //nixpkgs/constraints:nixpkgs, which does not match value @io_tweag_rules_nixpkgs//nixpkgs/constraints:nixpkgs from the execution platform @io_tweag_rules_nixpkgs//nixpkgs/constraints:linux_x86_64_nixpkgs

What operating system are you running Bazel on?

Ubuntun 19.10

What's the output of bazel info release?

release 2.0.0- (@non-git)

Also reproducible with 2.1.0.

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

Using Nix with the following nixpkgs revision

{
  "owner": "NixOS",
  "repo": "nixpkgs-channels",
  "branch": "nixpkgs-unstable",
  "rev": "e4af779056318fa830de52080dca08464d0d2bf9",
  "sha256": "0lnqr9lfavn89n66k48p8bcvcv0i2i84izwr5918qvq57dwzyjqm"
}

Have you found anything relevant by searching the web?

This seems related to the following issue #9177

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

This is a regression, the issue was not observed in Bazel version 1.1.0.

[gregestren]

I've seen a number of issues recently related to workspace prefixes. I wonder if there's any commonality between them. Regardless, we'll have a chat among configuration devs later this week and bring this up for triaging. Thanks for the detailed description.

[aiuto]

/cc @katre

[gregestren]

FYI I think this concern (better support for workspace prefixes) should be a commitment for Q2.

[aherrmann]

Thanks for the update, that's great to hear!

[jin]

@gregestren, could you replace the untriaged label with a priority label please?

[gregestren]

Let's consolidate these bugs into #11128.

When that one is fixed, it if doesn't address this we can re-open this.

[katre]

Note to myself:

Here's the worrying code: https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/skyframe/SingleToolchainResolutionFunction.java;drc=780199d619bbec2a7dd695773cc3018d4de6c1e7;l=138

The toolchainType Label from the actual toolchain target is directly compared to the toolchainType Label from the rule (either starlark's rule.toolchains parameter, or a native rule's RuleClass.Builder.addRequiredToolchains). The label from the rule isn't ever resolved, so a target isn't loaded. If it was, we could compare canonical labels and make sure it works, at the expense of an extra ConfiguredTarget lookup (although a cached one, almost certainly).

[katre]

See #13381 for details, but this should be fixed in Bazel at head.