Fix processwrapper in multiplatform builds

[dzbarsky]

The problem is that cfg = "exec" is not well-defined when you have multiple exec platforms. We want to build the wrapper for the same platform that the toolchain will be used on, and the way to achieve that is by making it an attribute of the toolchain itself.

Previously, building on a linux remote executor from a windows host was broken.

[UebelAndre]

I haven't fully understood the implementation here but I feel like cfg = "exec" should be whatever the configuration is for the platform running an action. If this is not the case I feel this should be addressed in Bazel directly and not something rules have to account for. Is there an issue for this somewhere already?

[dzbarsky]

I haven't fully understood the implementation here but I feel like cfg = "exec" should be whatever the configuration is for the platform running an action. If this is not the case I feel this should be addressed in Bazel directly and not something rules have to account for. Is there an issue for this somewhere already?

It looks like this may not be necessary for correctness in rules_rust today as we are emitting a single action, but as soon as we have cases where a rule does multiple actions, it will be broken because there's nothing forcing the tool into the same exec as the toolchain. (This is what exec groups do, so fixing it that way could be another fix).

However, I do think it's nicer to have this binary (which is conceptually part of the toolchain needed to run rustc_compile) be on the toolchain itself. That means third-party rules that need to rust rustc_compile can just use the toolchain without needing to add an extra magic attribute; i.e. the toolchain is encapsulated better.

cc @fmeum in case you have additional thoughts.

[fmeum]

I haven't fully understood the implementation here but I feel like cfg = "exec" should be whatever the configuration is for the platform running an action. If this is not the case I feel this should be addressed in Bazel directly and not something rules have to account for.

This behavior wouldn't necessarily be correct: An action could be executed on Windows but run a Linux tool (configured for a special Linux exec platform) in a container. It also wouldn't be possible to implement this since the action is considered by arbitrary Starlark in the rule impl, but the configuration of the deps has to be known before that's executed.

@dzbarsky An alternative would be a dedicated toolchain that's resolved together with rustc.

[dzbarsky]

I haven't fully understood the implementation here but I feel like cfg = "exec" should be whatever the configuration is for the platform running an action. If this is not the case I feel this should be addressed in Bazel directly and not something rules have to account for.

This behavior wouldn't necessarily be correct: An action could be executed on Windows but run a Linux tool (configured for a special Linux exec platform) in a container. It also wouldn't be possible to implement this since the action is considered by arbitrary Starlark in the rule impl, but the configuration of the deps has to be known before that's executed.

@dzbarsky An alternative would be a dedicated toolchain that's resolved together with rustc.

True, do you think that's preferable though? I feel like that would also leak this implementation detail to consumers (they'd need to depend on an extra toolchain when conceptually they just want a rust compiler). By consumer I mean rulesets that want to invoke rust compilation such as https://github.com/google/crubit etc

[fmeum]

Right, the toolchain would have to be a toolchain requirement of the rust toolchain target so that it's picked up automatically. But that's probably just more complex than what you are doing in this PR.