Splitting rust_toolchain into multiple toolchains

[UebelAndre]

Overview

This discussion is inspired by the desire to do cross-compilation with the rules. There seem to be many issues related to this (#770, #276, #207). The goal is to take advantage of Bazel's toolchain resolution and allow the rules to, by default, cover more target platforms without incurring a cost to build time by downloading unnecessary components.

The Problem

Defining target toolchains is clunky.

Currently, it's difficult to define an appropriate toolchain that supports the desired target platforms due to the implementation of rust_toolchain. rust_toolchain is monlithic as it contains everything in a rust asset bundle (clippy, cargo, rustc, rust-stdlib, rustfmt). The toolchain is typically defined by calling rust_repository_set which internally calls rust_toolchain_repository_proxy to produce a repository which contains

# ...

rust_toolchain(
    name = "toolchain_for_x86_64-apple-darwin_impl",
    rust_doc = "@rust_darwin_x86_64//:rustdoc",
    rust_lib = "@rust_darwin_x86_64//:rust_lib-x86_64-apple-darwin",
    rustc = "@rust_darwin_x86_64//:rustc",
    rustfmt = "@rust_darwin_x86_64//:rustfmt_bin",
    cargo = "@rust_darwin_x86_64//:cargo",
    clippy_driver = "@rust_darwin_x86_64//:clippy_driver_bin",
    rustc_lib = "@rust_darwin_x86_64//:rustc_lib",
    rustc_srcs = "@rust_darwin_x86_64//lib/rustlib/src:rustc_srcs",
    binary_ext = "",
    staticlib_ext = ".a",
    dylib_ext = ".dylib",
    stdlib_linkflags = ["-lSystem", "-lresolv"],
    os = "darwin",
    default_edition = "2015",
    exec_triple = "x86_64-apple-darwin",
    target_triple = "x86_64-apple-darwin",
    visibility = ["//visibility:public"],
)

# ...

rust_toolchain(
    name = "toolchain_for_wasm32-unknown-unknown_impl",
    # ...
)

# ...

rust_toolchain(
    name = "toolchain_for_wasm32-wasi_impl",
    # ...
)

These then get registered here:

rules_rust/rust/repositories.bzl

Lines 307 to 313 in 7e7246f

	all_toolchain_names = []
	for target_triple in [exec_triple] + extra_target_triples:
	all_toolchain_names.append("@{name}_toolchains//:{toolchain_name_prefix}_{triple}".format(
	name = name,
	toolchain_name_prefix = DEFAULT_TOOLCHAIN_NAME_PREFIX,
	triple = target_triple,
	))

The result is that there's now there's multiple nearly identical toolchains (in this case, toolchain_for_x86_64-apple-darwin_impl, toolchain_for_wasm32-unknown-unknown_impl, and toolchain_for_wasm32-wasi_impl) which only differ slightly by rust_lib and other fields like the *_ext fields. This is not a huge issue when you're only going to be building from one host/exec platform but in the case your project supports multiple, it can be pretty uncomfortable to now manage multiple rust_repository_set definitions with all the same target platforms.

Solution

By breaking up rust_toolchain we allow for users to separately register their host/exec toolchains (which should contain things like rustc and rustc_lib) and their target toolchains (which should contain rust-stdlib).

This can be achieved by splitting rust_toolchain into:

• rust_exec_toolchain: contains rustc, rustc_lib, default edition, exec triple, version info
• rust_target_toolchain: contains rust_stdlib, extension defs, target triple, version info

Each new toolchain is then accompanied by a repository rule rust_exec_toolchain_repository and rust_target_toolchain_repository. This allows for exec and target toolchains to only be defined once and relies more on Bazel's toolchain resolution which should result in interfacing with other rules easier and more intuitive (since they'd be sharing a similar interface).

Notes

The thing that ultimately set me down this journey was a conversation in the slack channel with @ccontavalli and @jmillikin where @jmillikin shared a great blog post about a cross-compilation journey which I felt clearly outlined the issues but also showed a credible path forward. This is my interpretation of that path forward. I'm curious what others think or if there's a better way to make toolchain resolution more intuitive and suited for cross compilation.

And also to note, this doesn't directly add support for cross compilation but I think is critical in maintaining cross-compilation projects.

Looking forward to collaborating on making cross-compilation an easier thing!

[UebelAndre]

I've got a draft PR (#800) of this open if anyone needs something more concrete than what I've written above. Please note it's just a draft and I'll only be able to retain high level feedback since it's still fairly volatile. Depending on how that issue goes, I may re-open it under a new PR to make it easier to review after some feedback/changes.

[UebelAndre]

I'm happy to report that that draft is now fully functional! The tricky part was realizing that because the previous (now current) implementation creates a canonical sysroot by downloading the rust and all rust-std artifacts to the same location. The trick was to use rust_toolchain to consume rust_exec_toolchain and rust_target_toolchain and generate this sysroot on demand (when the rust_toolchain is resolved). But alas, it still wasn't that simple because I ran into the same issue as #635 and couldn't have transitive toolchains (rules depend on rust_toolchain and rust_toolchain depend on rust_target_toolchain and rust_exec_toolchain). This was fixed by introducing a _rust_toolchain attribute 😞. I'm not sure if it's overkill or not but I ended up also adding a new repository rule to check the version of Bazel you're using and, if you're on at least 4.1.0 then the transitive toolchains will be used, which I feel is the better approach. But once the last required PR is closed I'll write up a pretty description for the changes and move it into "ready for review". In the mean time, I'd welcome interested parties to try it out but again, only high level feedback will be considered. I'd like to save nits and focused things once the approach is thought to be a good one 😄

[hlopko]

1. The proposal doesn't discuss the downsides of this refactoring.

   Rules that use a toolchain are typically written more often, and often by users less experienced with Bazel. Toolchains are often maintained more centrally by more experienced Bazel users. I claim it's more important to optimize primarily for the ease of use for rule authors, not for toolchain owners.

   If we split Rust toolchain into 2, each rule will have to declare dependencies on both. In the rule implementation users will have to typically pass both toolchains to all corners of the rule implementation because you typically need both tools and libraries to compile stuff. Bazel toolchains are designed to be able to encapsulate exec and target details of the toolchain.

2. I don't see how any of the linked issues (Support for custom targets #770, Document how to do cross-compilation #276, Support custom constraints in toolchains #207) is going to be fixed by the proposal or how fixing any of those requires this proposal to be implemented.

3. I believe "The goal is to take advantage of Bazel's toolchain resolution and allow the rules to, by default, cover more target platforms without incurring a cost to build time by downloading unnecessary components." is misleading:

   • Rules Rust take advantage of the toolchain resolution already
   • We currently cover 6 target platforms by default: https://github.com/bazelbuild/rules_rust/blob/main/rust/repositories.bzl#L24.
   • We currently only download one of those when it is actually needed by the build.

4. The proposal claims "Defining target toolchains is clunky.", but it doesn't show how will we define toolchains with this proposal. To me it seems the proposal will not change how extra toolchains are registered.

5. I think the argument that there are very similar toolchains is valid. Bazel supports 3 host platforms (Linux, Mac, Windows on x86_64 and arm64) and typically (even on RBE) one of those is also the execution platforms. I can see how toolchains executing on for example Linux and targeting different platforms will share the same tools, but different builds of the standard library. I can also see how in order to cover all cases supported by Bazel and Rust we will need to register 6 (number of Bazel exec platforms) times 20 (-ish target platforms that Rust supports if you divide by the count of exec platforms, I didn't actually count though). I don't think it is a problem that we would be registering these toolchains (as mentioned before, Bazel and rules_rust will not download anything unless it is needed by the build). I don't think it will (the code does a linear search through all the registered toolchains once per configuration, of which we usually have 1), but if you can show that Bazel toolchain resolution of 120 toolchains slows down the build, please file an issue against Bazel.

Therefore I propose either or both of:

• consider registering more toolchains by default so users don't have to use rust_repository_set as often
• investigate how rust_repository_set and related functions could be made more ergonomic to use with current design of rust_toolchain.

[UebelAndre]

1. The proposal doesn't discuss the downsides of this refactoring.
   Rules that use a toolchain are typically written more often, and often by users less experienced with Bazel. Toolchains are often maintained more centrally by more experienced Bazel users. I claim it's more important to optimize primarily for the ease of use for rule authors, not for toolchain owners.
   If we split Rust toolchain into 2, each rule will have to declare dependencies on both. In the rule implementation users will have to typically pass both toolchains to all corners of the rule implementation because you typically need both tools and libraries to compile stuff. Bazel toolchains are designed to be able to encapsulate exec and target details of the toolchain.

Splitting them optimizes for both. You do need tools and libraries to build but you currently must define both at the same time in a single toolchain which means if you aim to support building on multiple platforms and target multiple platforms, you have pretty redundant toolchains. Allowing the rules to depend on both an exec toolchian which contains tools and a target toolchain which contains libraries means there's less duplication for the toolchain author. In this proposal. This, in my opinion is easier for the rule authors and allows them to predefine more target platforms without incurring a heavy download for users. An example being, every single toolchain includes the wasm target even though they're rarely used in comparison. Allowing these target libraries to be declared separately means we could define a toolchain for all of them in a simple and readable way with no additional cost to the user.

2. I don't see how any of the linked issues (#770, #276, #207) is going to be fixed by the proposal or how fixing any of those requires this proposal to be implemented.

This proposal would not solve for any of these but is something I feel stands in the way of a simple and clean resolution for each. By splitting the toolchains, we wouldn't be forcing users to deal with the spaghetti of rust_repository_set which I feel would be a big bonus (#770). I also think by splitting the toolchains, the rules align more closely with how platform support is discussed in the rust book, which I think would make documenting and maintaining cross-compilation support easier (#276). And finally, I don't see a clear way (for authors or users) to wire up custom constraint values with rust_repository_set since this commonly defines a 1-many toolchain. Having an exec and target toolchain would simplify defining custom constraints (#207).

I believe "The goal is to take advantage of Bazel's toolchain resolution and allow the rules to, by default, cover more target platforms without incurring a cost to build time by downloading unnecessary components." is misleading:

* Rules Rust take advantage of the toolchain resolution already

* We currently cover 6 target platforms by default: https://github.com/bazelbuild/rules_rust/blob/main/rust/repositories.bzl#L24.

* We currently only download one of those when it is actually needed by the build.

True, the rules do use toolchain resolution.

We currently support 6 platforms (+ 2 additional target platforms). We cannot support more without having a massive toolchain or exploding how many we define. Again, this is because rust_repository_set forces a 1-many relationship. By splitting the toolchains, we can support 6 exec platforms + all supported target platforms with no additional overhead to the user since the resolution would happen on a per target basis. This to me is taking more advantage of toolchain resolution since the way the rules are defined now, we generally have a repository generated with all capabilities and a toolchain that only differs in flags needed by each target. Instead, we should use toolchain resolution to gate what artifacts need to be downloaded in order to perform a build, in addition to providing target specific flags (which is the part already being done).

We download one "exec collection" which will include all extra_target_triple stdlibs.

Contents of rust_darwin_x86_64 repository:

BUILD.bazel*                                   etc/                                           llvm-tools-1.53.0-x86_64-apple-darwin.tar.gz   rust-std-1.53.0-wasm32-unknown-unknown.tar.gz  rustc-1.53.0-src.tar.gz
WORKSPACE.bazel*                               lib/                                           manifest.in                                    rust-std-1.53.0-wasm32-wasi.tar.gz             rustfmt-1.53.0-x86_64-apple-darwin.tar.gz
bin/                                           libexec/                                       rust-1.53.0-x86_64-apple-darwin.tar.gz         rust-std-1.53.0-x86_64-apple-darwin.tar.gz     share/

4\. The proposal claims "Defining target toolchains is clunky.", but it doesn't show how will we define toolchains with this proposal. To me it seems the proposal will not change how extra toolchains are registered.

I posted #815 (comment) but you're correct, I should have also explained the implementation more clearly in the post. Extra toolchains would be additional calls to rust_target_toolchain_repository (name TBD) which would be a single additional call and work with all exec environments. Again, if we can define the 6 host/exec toolchains we support separately of target toolchains, we could define a much larger number of target toolchains and eliminate the need for most users needing to do this and for those who do, it's one additional call that doesn't force them to unnecessarily download more data for every environment.

5\. I think the argument that there are very similar toolchains is valid. Bazel supports 3 host platforms ([Linux, Mac, Windows](https://bazel.build/#one-tool-multiple-languages) on `x86_64` and `arm64`) and typically (even on RBE) one of those is also the execution platforms. I can see how toolchains executing on for example Linux and targeting different platforms will share the same tools, but different builds of the standard library. I can also see how in order to cover all cases supported by Bazel and Rust we will need to register 6 (number of Bazel exec platforms) times 20 (-ish target platforms that Rust supports if you divide by the count of exec platforms, I didn't actually count though). I don't think it is a problem that we would be registering these toolchains (as mentioned before, Bazel and rules_rust will not download anything unless it is needed by the build). I don't think it will (the code does a linear search through all the registered toolchains once per configuration, of which we usually have 1), but if you can show that Bazel toolchain resolution of 120 toolchains slows down the build, please file an issue against Bazel.

It's not true that the rules will not download anything extra. It won't download an additional rustc binary or something, but users will always download additional rust-stdlib artifacts which would make defining additional target platforms worse and worse on your build performance.

Therefore I propose either or both of:

* consider registering more toolchains by default so users don't have to use `rust_repository_set` as often

* investigate how `rust_repository_set` and related functions could be made more ergonomic to use with current design of `rust_toolchain`.

I do not think we should be using rust_repository_set to register additional default toolchains. The rule generates toolchains which contain far too much additional data (cargo, clippy, rustfmt) and having a wide set of supported target platforms would only make that worse.

I feel strongly that a rust_toolchain which is both exec and target is the problem and forces a lot of duplicate information and requires users to download more than they should. I don't see how splitting the toolchain would come at a cost to rule authors or users. I can only see it as simplifying things and improving over all build performance.

[hlopko]

Splitting them optimizes for both. You do need tools and libraries to build but you currently must define both at the same time in a single toolchain which means if you aim to support building on multiple platforms and target multiple platforms, you have pretty redundant toolchains. Allowing the rules to depend on both an exec toolchian which contains tools and a target toolchain which contains libraries means there's less duplication for the toolchain author. In this proposal. This, in my opinion is easier for the rule authors and allows them to predefine more target platforms without incurring a heavy download for users. An example being, every single toolchain includes the wasm target even though they're rarely used in comparison. Allowing these target libraries to be declared separately means we could define a toolchain for all of them in a simple and readable way with no additional cost to the user.

I'm postulating that toolchain authors and rules authors are often enough not the same people, and for rules authors what you propose is a regression. For maintainers of the rules_rust your proposal (and your draft implementation) incur a lot of complexity that is on you to prove is warranted.

You keep mentioning a heavy download for users, but the current solution does not force us to download anything unnecessary. The way wasm is handled currently is not an evidence of a limitation of the current solution, it's an evidence of a suboptimal implementation. Wasm (wasm32-unknown-unknown) should have its own external repository and it should not be polluting x86_64-unknown-linux-gnu. Fixing this would be a simple change, uncontroversial, and a very welcomed one.

This proposal would not solve for any of these but is something I feel stands in the way of a simple and clean resolution for each. By splitting the toolchains, we wouldn't be forcing users to deal with the spaghetti of rust_repository_set which I feel would be a big bonus (#770). I also think by splitting the toolchains, the rules align more closely with how platform support is discussed in the rust book, which I think would make documenting and maintaining cross-compilation support easier (#276). And finally, I don't see a clear way (for authors or users) to wire up custom constraint values with rust_repository_set since this commonly defines a 1-many toolchain. Having an exec and target toolchain would simplify defining custom constraints (#207).

What I read from this paragraph is:

• rust_repository_set is hard to use and is not handling all use cases -> we should fix it, or come up with something better
• you write that split toolchains would make it easier to document how to do cross compliation (Document how to do cross-compilation #276). I am not convinced that the reason docs don't exist is that current rust_toolchain makes it hard to document how to do cross compilation, the reason is that nobody spent time documenting it.
• Support custom constraints in toolchains #207 is not asking for overriding constraints just because they want to do that, they ask to be able to use constraints that don't exist in https://github.com/bazelbuild/platforms, but that rustc supports. Their goal is to be able to cross compile to targets that are not represented by https://github.com/bazelbuild/platforms. This is again an example of a use case that is not well supported by out repository rules. For constraints that don't exist in @platforms, I propose to create them in rules_rust and use them when needed. I think with that there is no further need to override constraints.

We currently support 6 platforms (+ 2 additional target platforms). We cannot support more without having a massive toolchain or exploding how many we define.

I don't see a problem with pre-defining 120 toolchains as long as none of them re-downloads stuff that other toolchains downloaded, and none of them downloads unnecessary things. All can be achieved with a current rust_toolchain design.

Again, this is because rust_repository_set forces a 1-many relationship. By splitting the toolchains, we can support 6 exec platforms + all supported target platforms with no additional overhead to the user since the resolution would happen on a per target basis.

What do you mean by overhead to the user? I postulate that time to do toolchain resolution from 6 toolchains + toolchain resolution from 20 toolchains will be the same as time to do toolchain resolution of 120 toolchains once. It's all within noise, there is no reason to optimize this.

This to me is taking more advantage of toolchain resolution since the way the rules are defined now, we generally have a repository generated with all capabilities and a toolchain that only differs in flags needed by each target. Instead, we should use toolchain resolution to gate what artifacts need to be downloaded in order to perform a build, in addition to providing target specific flags (which is the part already being done).

Ok I think this is where we don't understand each other. Please tell me why the following hypothetical repository layout doesn't work (using hypothetical so we don't get bogged down to current impl details):

@rust_toolchains is a repository rule that defines 120 toolchain targets. Each of those 120 toolchains will have in its toolchain attribute a label to a separate repository, for example for x64_64:

toolchain(
    name = "rust_linux_x86_64",
    exec_compatible_with = [
        "@platforms//cpu:x86_64",
        "@platforms//os:linux",
    ],
    target_compatible_with = [
        "@platforms//cpu:x86_64",
        "@platforms//os:linux",
    ],
    toolchain = "@rust_toolchain_x86_64//:rust_toolchain",
)
...
register_toolchains("//:all")

Then in the @rust_toolchain_x86_64:

rust_toolchain(
  name = "rust_toolchain",
  rustc = ["@rust_tools_linux//:rustc"],
  rust_lib = ["@rust_stdlib_x86_64//:rust_lib"],
  ...
)

With this layout, we only eagerly load the @rust_toolchains//:BUILD file and register all the toolchains there. Once a particular toolchain is resolved, we load and analyze its corresponding @rust_toolchain_x86_64 repository and the BUILD file there. Because @rust_toolchain_x86_64//:rust_toolchain depends on other repositories for tools and libraries, we need to download them now. We didn't have to download them before, and we only need to download them for the toolchain that is being used by an actual build. We don't need to download all the toolchains eagerly. We only download what the user explicitly requrested by passing the --platforms bazel option. Please tell me if I'm not understanding something there.

Because we have @rust_tools_linux repository that downloads the tools, all different rust_toolchains that need these tool will reuse these artifacts. The same goes for stdlib. There is no unnecessary re-downloading of things.

I posted #815 (comment) but you're correct, I should have also explained the implementation more clearly in the post. Extra toolchains would be additional calls to rust_target_toolchain_repository (name TBD) which would be a single additional call and work with all exec environments. Again, if we can define the 6 host/exec toolchains we support separately of target toolchains, we could define a much larger number of target toolchains and eliminate the need for most users needing to do this and for those who do, it's one additional call that doesn't force them to unnecessarily download more data for every environment.

We can define all the possible 120 toolchains just as well. No unnecessary data is downloaded.

It's not true that the rules will not download anything extra. It won't download an additional rustc binary or something, but users will always download additional rust-stdlib artifacts which would make defining additional target platforms worse and worse on your build performance.

I don't see why users would have to download any unnecessary stdlibs. In the example above I show how they only need to download what they need for the current build. Nothing more.

I do not think we should be using rust_repository_set to register additional default toolchains. The rule generates toolchains which contain far too much additional data (cargo, clippy, rustfmt) and having a wide set of supported target platforms would only make that worse.

Are you proposing to remove clippy/rustfmt/cargo from the rust_toolchain? That is a different proposal than the one we are talking about. Please let's not make this one cover more ground than necessary. I'm happy to have a separate discussion for this.

I feel strongly that a rust_toolchain which is both exec and target is the problem and forces a lot of duplicate information and requires users to download more than they should. I don't see how splitting the toolchain would come at a cost to rule authors or users. I can only see it as simplifying things and improving over all build performance.

I remain not convinced that this proposal will have any measurable effect on amount of downloaded data and build performance. I still think the biggest usability wins for the toolchain owners are to be held at our repository rules, not in the rust_toolchain. Looking at your draft PR I am skeptical that the split will simplify the implementation.

[UebelAndre]

After a conversation with @hlopko I finally found the time to try a different interface.

rust_repository_set could maybe be expanded to accept a tuple of triple to constraints to possibly satisfy the desire of having more control over toolchain definitions and constraints

rust_repository_set(
    prefix = "some_prefix",
    edition = "2018",
    exec_triples = [
        "x86_64-unknown-linux-gnu",
        ["aarch64-unknown-linux-gnu", "@platforms//cpu:aarch64"],
    ],
    target_triples = [
        "x86_64-unknown-linux-gnu",
        ["aarch64-unknown-linux-gnu", "@platforms//cpu:aarch64"],
        ["x86_64-unknown-linux-musl", "//custom:constraint"],
        ["aarch64-unknown-linux-musl", "@platforms//cpu:aarch64", "//custom:constraint"],
        ["i686-unknown-linux-gnu"]
    ],
    rustfmt_version = "1.4.12",
    sha256s = {
        "rust-1.46.0-x86_64-unknown-linux-gnu": "e3b98bc3440fe92817881933f9564389eccb396f5f431f33d48b979fa2fbdcf5",
        "rust-std-1.46.0-x86_64-unknown-linux-gnu": "ac04aef80423f612c0079829b504902de27a6997214eb58ab0765d02f7ec1dbc",
        "rustfmt-1.4.12-x86_64-unknown-linux-gnu": "1894e76913303d66bf40885a601462844eec15fca9e76a6d13c390d7000d64b0",
    },
    version = "1.46.0",
)

This approach allows users to pass a list or string to exec_triples and target_triples where if the value is a string, the default set of constraints is assumed from triple_to_constraint_set and any list is assumed to be explicitly providing constraints (even if no constraints are added). rust_repository_set would then wire everything up in to repositories named after prefix looking something like {prefix}_toolchain_{version}_{exec_triple}_{target_triple}.

One thing that bothers me about this approach is that it has an uncommon API where a single attribute consumes multiple types of data and generates a different structure to have something that can be iterated over. I feel that by introducing any API that doesn't simply allow users to set exec and target constraints is unnecessary burden of knowledge and adds a step to debugging why the rules might not be doing what's expected after the normal toolchain resolution debugging. In the other variants I've attempted, they all come down to this issue. I'm still convinced that having separate execution and target toolchains is the right approach to allow for custom constrained toolchains without re-implementing toolchain resolution in repository rules or forcing users to copy/paste whole toolchain definitions. However, there could still be an approach I'm not seeing.

[hlopko]

CC @katre @durin42 @krasimirgg . To sum it up, we're thinking about splitting rust_toolchain into rust_exec_toolchain and rust_target_toolchain (former will have all attrs in exec configuration, latter in target configuration). The benefit is that split toolchains are more convenient to register in repository rules (and if we want to support M exec platforms and N target platforms we only need M + N toolchains, wheras with a single toolchain we need M * N toolchains), the downside is that we will no longer have a single Rust toolchain type.

What do you think about that? Has that been investigated by other rules that you know of? Is there a reason why we shouldn't further have a toolchain type per executable (rust compiler, rust formatter, rust static analysis tool all having their own toolchain types) and one for the standard library?

[katre]

Will rust_exec_toolchain and rust_target_toolchain have the same attributes or different? It is possible to have a single toolchain which mixes exec and target attributes, if that would be simpler.

That said, I don't see anything wrong with splitting out the toolchain types if that's the logical boundary that makes sense with your project. Splitting even further (to one per tool) is also possible, but I feel like there may be a lot of commonalities that are being ignored in that case.

[hlopko]

They will mostly have different attributes. Think of the split as if cc_toolchain had clang binary in the "exec" toolchain, and libc++.a in the "target" toolchain. But most rules will need to depend on both of these toolchains (actually, we will likely need rust_toolchain that rules will depend on, rust_toolchain will setup sysroot, and that one will depend on both rust_exec_toolchain and rust_target_toolchain, but only after transitive toolchains are implemented in Bazel).

[UebelAndre]

Any more thoughts on this?

[hlopko]

Some random thoughts:

• would it be possible to construct the triple from constraints?
• it not, would it be more readable to have some kind of make_triple function that creates a struct? This way we shouldn't need to use "reflection" to figure out what did the user pass into target_triples or exec_triples?
• if not, would it be non ergonomic to require user to always pass [] when meaning no additional constraints?

[UebelAndre]

* would it be possible to construct the triple from constraints?

I don't think the rules could reliably make this call. It'd have to be to some sane default or there'd have to be a mechanism for users to define this (for the time being). Bazel doesn't really have a concept of ABI but this is core to Rust triples x86_64-unknown-linux-gnu/x86_64-unknown-linux-musl. So if Bazel were to define that then this might be a good reality.

* it not, would it be more readable to have some kind of `make_triple` function that creates a struct? This way we shouldn't need to use "reflection" to figure out what did the user pass into `target_triples` or `exec_triples`?

Interesting, can you elaborate here? What do you envision the struct would look like? Just a broken down version of the triple?

* if not, would it be non ergonomic to require user to always pass `[]` when meaning no additional constraints?

Yeah, I think this is a good pattern. Omitting constraints should default to the current defaults. Users who pass anything should get exactly what they requested. Including an empty set (no constraints).

[UebelAndre]

While I still think the toolchain should be split into exec and target variants, It's definitely still possible through macro magic and repository rules to get the same results. I'm currently working on at least allowing toolchains to support artifacts from different repositories so each toolchain doesn't have to be a rust asset bundle with a variety of rust_std bundles. This should save quite a bit of time downloading bundles without changing the toolchain interface itself.