Disambiguate ARM hard-float vs soft-float (and WASM threads) target triples

[pcrumley]

Problem

The generated toolchains select() on per-triple config_settings whose constraints came from triple_to_rust_constraint_set() — cpu, os, libc, but no float-ABI or WASM-threads bit. So 7 groups of triples projected to identical constraint sets (the arm/armv7 × gnu/musl eabi/eabihf pairs, thumbv8m.main-none-eabi/eabihf, aarch64-unknown-none/-softfloat, and wasm32-wasip1/wasm32-wasip1-threads), and building for a matching platform failed with Illegal ambiguous match on configurable attribute "target_triple".

Fix

New constraints in rs/platforms/constraints/BUILD.bazel: a float_abi setting (hardfloat default / softfloat) and a wasm_threads setting (wasm_threads_off default / wasm_threads_on). The defaults are the conventional/plain variant so existing platforms resolve unchanged; the other variant opts in explicitly.

triple_to_rust_constraint_set (rs/platforms/triples.bzl) appends a disambiguator only when a triple has a sibling that is also in the target set and projects to the same base constraint set — a genuine collision. This covers the eabi↔eabihf, -softfloat-suffix, and -threads-suffix encodings. Scoping to actual base-set equality leaves lone targets untouched and skips pairs that already differ (e.g. thumbv7em-none-eabi/eabihf, which rules_rust already maps to distinct CPUs), so non-annotated consumers keep resolving. The targets list is threaded through to the config-settings, platforms, and toolchain projections so a custom triple subset stays self-consistent. No change to the select() construction is needed — unique config settings disambiguate on their own.

New Starlark suite in rs/platforms/triples_test.bzl asserts the uniqueness invariant over all triples, that each colliding pair is separated by a distinct disambiguator, and that lone targets gain none. README "Cross ABI target details" documents the new constraints.

Verification

//rs/platforms:all and //rs/private:all tests pass. @default_rust_toolchains//:all loads with distinct aarch64_unknown_none vs _softfloat toolchains. bazel cquery across all eight previously-colliding platforms resolves cleanly with no ambiguous match. config:arm-unknown-linux-musleabi → […, musl, softfloat] vs musleabihf → […, musl, hardfloat]. Non-ARM/non-WASM config settings and platforms are unaffected. No triples removed and no consumer-facing tags/attributes changed.

proposed fix for #153

[dzbarsky]

@pcrumley Hello again :) My apologies for this papercut - it's a gap I've been aware of but was putting off because the right home for these constraints is in https://github.com/bazel-contrib/platforms_contrib which is getting actively built out. (cc @fmeum) But since you've hit this, I think it's fine if we fix it here and later alias to contrib + deprecate these constraints; it's not the end of the world

Could you take a look at my suggestions and check if it's doable to simplify?

[dzbarsky]

I don't understand why the mechanism above is different from the one below, can we just follow the pattern below, it seems easier to reason about?

[pcrumley]

yeah the reason is you do need to call out to a helper to see if there is a sibling triple, however, you can keep the inline in here and only have at sibling logic be a helper.

[dzbarsky]

I wonder if we could just have a simple rust target that we transition to all target triples as more of an integration test vs this testing internals?

[pcrumley]

I thought it would be too heavy to have to pull in a toolchain for every target platform, and for some of the platforms you get cc toolchain errors for even very simple targets. I think i figured out a way that still actually iterates over all of triples and doesn't just sort of test the own internal logic of it. This test is still a red-green test from this change