Tracking issue for wasm32-unknown-unknown's future-incompat warning for C ABI changes

[alexcrichton]

This issue is intended to be a tracking issue for the future-incompat warning being added in #138601. This lint is notifying users of an upcoming change to the C ABI used by the wasm32-unknown-unknown target, notably around passing aggregates-by-value in parameter position. An exampe of code that will change is:

#[repr(C)]
pub struct Pair {
    x: u32,
    y: u32,
}

#[unsafe(no_mangle)]
pub extern "C" fn pair_add(pair: Pair) -> u32 {
    pair.x + pair.y
}

where today this generates:

(func $pair_add (param i32 i32) (result i32)
  local.get 1
  local.get 0
  i32.add
)

but in the future this will generate:

(func (param i32) (result i32)
  local.get 0
  i32.load offset=4
  local.get 0
  i32.load
  i32.add
)

More details about this change and its history can be found in the blog post associated with this change. In short though users need to do one of the following to resolve the warnings:

1. Pin to a stable compiler and don't update until the default has changed.
2. Update to nightly, pass -Zwasm-c-abi=spec, and then use that until the default changes. This means signatures will change immediately and work will be necessary to port external JS for example.
3. Update to nightly, pass -Zwasm-c-abi=legacy. This will silence the warnings but be warned that code will still break in the future when the ABI changes.
4. Update function signatures to not pass aggregates-by-value, but instead pass them by reference. This works both today and with the future ABI.

The current plan is to change the default ABI mid-summer 2025. This'll get updated with exact timelines as things happen. More background can be found in #122532

Implementation history

• add FCW to warn about wasm ABI transition #138601
• Don't warn about v128 in wasm ABI transition #139809
• Ignore zero-sized types in wasm future-compat warning #139498

[SimonSapin]

Is the wasm32v1-none target affected by this ABI change?

The blog post suggests no: “If you don't use the wasm32-unknown-unknown target, you are not affected by this change.” But the target is documented as “very similar to wasm32-unknown-unknown” with ABI not mentioned in the list of “only three minor differences”

[alexcrichton]

No, wasm32v1-none is not affected, it's already using the correct ABI definition

[danielhjacobs]

Every use of #[wasm_bindgen] in our code or our dependencies is causing the warning "this function definition involves an argument of type () which is affected by the wasm ABI transition". Is that accurate? rustwasm/wasm-bindgen#3454 seems to imply wasm-bindgen is now compliant with the "C" ABI.

[danielhjacobs]

The wasm-bindgen folks say this is a false positive.

[alexcrichton]

Yes, that's a false positive, and I've submitted #139498 to update the lint.

[hkratz]

This causes warnings when using simd, e.g. for

use std::arch::wasm32::{
    v128,
    v128_any_true};

#[no_mangle]
pub fn any_true(a: v128) -> bool {
    v128_any_true(a)
}

see https://godbolt.org/z/333b8n7dY

[alexcrichton]

I've sent #139809 to address that