Fix wasm staticlib extensions

[adincebic]

rust_static_library targets fail for wasm-style platform mappings whose staticlib_ext is empty.
This became visible after #3864 changed the allocator shim target to use rust_static_library. When building that target for the wasm platform, rules_rust computes:

  crate_type = "staticlib"
  staticlib_ext = ""

determine_lib_name treats the empty extension as invalid and fails with:

Unknown crate_type: staticlib

Static library outputs for these wasm/WASI-style targets should use archive output names, e.g. libfoo.a. Binary and dylib outputs can continue using .wasm.

This updates the wasm-style staticlib mappings to .a for:

• threads
• unknown
• wasi
• wasip1
• wasip2

This is easily reproducible from the rules_rust repository, before this change:

bazel build --platforms=//rust/platform:wasm32 //ffi/rs/allocator_library:allocator_library

fails during analysis with:

  Unknown crate_type: staticlib

closes #3894

[UebelAndre]

Thanks! Can you link any documentation that shows .a to be the correct value here? I'm not super familiar with wasm but I haven't heard of a static library being built for wasm. I'd like to avoid picking an arbitrary value so any context will help

[adincebic]

Thanks! Can you link any documentation that shows .a to be the correct value here? I'm not super familiar with wasm but I haven't heard of a static library being built for wasm. I'd like to avoid picking an arbitrary value so any context will help

Ok here is what I gathered, keep in mind that I am not that familiar with this ruleset or Rust language in general.

The Rust Reference describes --crate-type=staticlib as producing a “static system library” and says that staticlib outputs use *.a except for MSVC, where they use *.lib:
https://doc.rust-lang.org/reference/linkage.html#linkage

rustc also models this as a separate target option from executable/dynamic-library suffixes. TargetOptions has:

• exe_suffix
• dll_suffix
• staticlib_prefix
• staticlib_suffix

and the documented default for staticlib_suffix is .a:
https://doc.rust-lang.org/nightly/nightly-rustc/rustc_target/spec/struct.TargetOptions.html#structfield.staticlib_suffix

The wasm base target options explicitly set executable and dylib-style outputs to .wasm:

exe_suffix: ".wasm".into(),
dll_prefix: "".into(),
dll_suffix: ".wasm".into(),

but they do not override staticlib_suffix; they fall through to ..Default::default(), so the staticlib suffix remains rustc’s default .a:
https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_target/spec/base/wasm.rs.html

The concrete wasm targets are built from those wasm base options. For example:

• wasm32-unknown-unknown uses base::wasm::options(): https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_target/spec/targets/wasm32_unknown_unknown.rs.html
• wasm32-wasip1 also starts from base::wasm::options() and then sets WASI-specific OS/env/linking options: https://doc.rust-lang.org/beta/nightly-rustc/src/rustc_target/spec/targets/wasm32_wasip1.rs.html
• wasm32-wasip1-threads inherits the same wasm/WASI base behavior: https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_target/spec/targets/wasm32_wasip1_threads.rs.html

So my reading is that .wasm is correct for executable/cdylib-like wasm outputs and .a is correct for staticlib outputs because rustc treats those as static archive artifacts, not final wasm modules.
In this case, the allocator target is a rust_static_library, so it should follow rustc’s staticlib_suffix, not the wasm executable/dylib suffix.

[UebelAndre]

Thank you for that write-up!