Toolchain resolution appears broken with rules_rust toolchains

[scasagrande]

Just starting to take a look at rules_rs so this may be pebkac

For a reproducer, if you start with https://github.com/bazel-starters/rust , follow the instructions, but update rules_rs to 0.0.31+ (which is when rules_rs introduced its own toolchains), you will get

While resolving toolchains for target @@rules_rs++crate+crates__rand-0.8.5//:rand (bb02cf4): No matching toolchains found for types:
  @@rules_rs++rules_rust+rules_rust//rust:toolchain_type

I'm seeing the same in my own repos.

Thoughts?

[dzbarsky]

@scasagrande In order to properly model Rust triples, the toolchains we provide have extra constraints compared to rules_rust. (For example we properly support both gnu and musl for Linux, and msvc/gnu/gnullvm for Windows). However, it means you need to take a bit more care when specifying your platforms so the toolchains can match properly. Please take a look at https://github.com/dzbarsky/rules_rs?tab=readme-ov-file#platform-configuration

Open to suggestions how to make this clearer in the docs!

[scasagrande]

Ah! Yes I missed that. I'll take a closer look tomorrow.

[dzbarsky]

It's a bit buried toward the bottom, perhaps it should be higher up in the README or linked from toolchains section or something...

[scasagrande]

Alright, taking a look again I have 2 comments

1. I believe my confusion comes from the toolchains section, where option B section is empty. Perhaps a simple linked example in this section would be enough here.
2. My exploration here is focused on adding a slim bazel overlay to an existing cargo workspace repo, and perhaps add it to the BCR. I'd like to enable projects that depend on this module to be able to bring their existing rust toolchain and not have to make platform/bazelrc changes to accommodate internal implementation details of dependencies. For my use case I can deal with this, but for publishing to the BCR I feel it would be confusing for consumers.

[scasagrande]

Oh, I should also mention that right now I'm also just doing local native macOS builds.

[dzbarsky]

Apologies for the wall of text...

So the BCR story is going to be really tough unfortunately. The core problem is that rules_rs does this trick to consume rules_rust, because we have a bunch of fixes that have not landed to upstream - many of these PRs are open for months and hard-blocked by maintainers for non-technical reasons 😢

However, the result is that when downstream modules consume rules_rust via bazel_dep, the module graph has 2 separate copies, and things like the toolchain_type symbols for the toolchains don't match up. I have been discussing how to enable interop with the rules_rust maintainers for a few weeks now and sent bazelbuild/rules_rust#3857 but it is again blocked for non-technical reasons, so I'm losing hope that we'll be able to resolve this in a way that the rulesets can interop.

All that said, the other mitigation on our end is we try to make crate.from_cargo interop with both the rules_rs toolchains and the rules_rust toolchains via the use_experimental_platforms flag. If you're not setting it, I would expect that toolchain resolution should match rules_rust toolchains. We'll still have the issue where we combine deps and proc_macro_deps both into deps attribute because we rely on bazelbuild/rules_rust#3605 (we need that because there is actually no way to know whether a given crate is normal or proc-macro at crate resolution time, since it's not exposed in any registry metadata)

Anyway, let me try to take a peek at the starter over the weekend and see if there's anything easy we can do on our end to support it, but my fear is that this is an uphill battle and I've already spent so much energy trying to upstream things to rules_rust without much luck, thus it's better to focus on forward progress. It's going to be bumpy for a while though :(

[scasagrande]

Hmmm interesting. I appreciate the insight here.

For now I'll change my approach and ignore the BCR. In that case I'll switch to consuming this code as a non-module dependency and setup whatever is needed in my monorepo. If I can get that working with my existing rules_rust toolchains then I'll be happy for now.

[dzbarsky]

I did just realize that I can probably vendor some of the rust_binary/rust_library code into this repo to workaround the lack of bazelbuild/rules_rust#3605, i'll give that a try over the weekend

If you have some time to give rules_rs toolchains a spin as well, would appreciate it! (I guess they're a bit inflexible in that they are coupled with constraints from https://github.com/cerisier/toolchains_llvm_bootstrapped, but on the plus side you get a very out-of-the-box setup for C + Rust fully hermetic cross-build)

[scasagrande]

Giving them a rip is on my todo list, but since my cross compilation is working for my needs its not a high priority. In my case to get around the cargo splicing problem I vendored out all my crate dep build files. Ultimately I would like to move away from that and allow the rust developers to just modify cargo files and rules_rs would certainly help there.

[dzbarsky]

Makes sense! If it's helpful I'm happy to spend a bit of time pairing with you next week to help get you sorted out

[scasagrande]

I wouldn't be able to screen share so let me try on my own first and then we'll see what we can do 😄

[dzbarsky]

I added a bit clearer explanation for toolchains option B, in case it helps 3822d99

[dzbarsky]

@scasagrande hi, hope you're doing well! Wanted to check in and see how your migration is going and if there's anything we can do to help!

[scasagrande]

Been dealing with all sorts of other build/ci/etc problems lately so I had to take a break from this 😅