cc_toolchain_suite uses gets incorrect paths when toolchains are in a different repository from the cc_toolchain_suite

[illicitonion]

Description of the bug:

With C++ toolchain resolution disabled, cc_toolchain_suite currently assumes that all of the toolchains in it are in the same repository as the cc_toolchain_suite itself.

This means that calculated paths to tools are incorrect.

This was introduced in the starlarkification of CcToolchainProviderHelper in d30fcf2f09021aa624a7954acfe563a9c8c622a2. Before that commit, this worked.

(Note: The codepath where --incompatible_enable_cc_toolchain_resolution is enabled works fine)

Which category does this issue belong to?

C++/Objective-C Rules, Starlark Integration

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

Clone https://github.com/illicitonion/repro-bazel-cc-toolchain-starlark-paths cd into the consumer directory, and run bazel build :gr.

Which operating system are you running Bazel on?

macOS

What is the output of bazel info release?

release 7.0.0-pre.20230823.4

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

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

d30fcf2f09021aa624a7954acfe563a9c8c622a2

Have you found anything relevant by searching the web?

No response

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

No response

[illicitonion]

Note: I previously fixed this for the Java implementation in 04ab2c0449d6f257cccf659f106e86f36c58b3d4.

[comius]

I don’t know how much it makes sense to fix this, since we’re removing legacy C++ toolchain configuration and with it cc_toolchain_suite. So there will soon be no code to apply the fix to.

In the other hand the mechanism is still available with Bazel 7.

cc @buildbreaker2021