Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
alexcrichton opened this issue Mar 21, 2025 · 0 comments
Labels
A-ABI Area: Concerning the application binary interface (ABI) C-future-incompatibility Category: Future-incompatibility lints C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC O-wasm Target: WASM (WebAssembly), http://webassembly.org/ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@alexcrichton
Copy link
Member

alexcrichton commented Mar 21, 2025

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

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Mar 21, 2025
@alexcrichton alexcrichton changed the title Tracking issue for wasm32-unknown-unknown's future-incompat warning Tracking issue for wasm32-unknown-unknown's future-incompat warning for C ABI changes Mar 21, 2025
@jieyouxu jieyouxu added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. O-wasm Target: WASM (WebAssembly), http://webassembly.org/ C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC C-future-incompatibility Category: Future-incompatibility lints A-ABI Area: Concerning the application binary interface (ABI) and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Mar 21, 2025
tgross35 added a commit to tgross35/rust that referenced this issue Mar 22, 2025
add FCW to warn about wasm ABI transition

See rust-lang#122532 for context: the "C" ABI on wasm32-unk-unk will change. The goal of this lint is to warn about any function definition and calls whose behavior will be affected by the change. My understanding is the following:
- scalar arguments are fine
  - including 128 bit types, they get passed as two `i64` arguments in both ABIs
- `repr(C)` structs (recursively) wrapping a single scalar argument are fine (unless they have extra padding due to over-alignment attributes)
- all return values are fine

`@bjorn3` `@alexcrichton` `@Manishearth` is that correct?

I am making this a "show up in future compat reports" lint to maximize the chances people become aware of this. OTOH this likely means warnings for most users of Diplomat so maybe we shouldn't do this?

IIUC, wasm-bindgen should be unaffected by this lint as they only pass scalar types as arguments.

Tracking issue: rust-lang#138762
Transition plan blog post: rust-lang/blog.rust-lang.org#1531
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Mar 24, 2025
add FCW to warn about wasm ABI transition

See rust-lang#122532 for context: the "C" ABI on wasm32-unk-unk will change. The goal of this lint is to warn about any function definition and calls whose behavior will be affected by the change. My understanding is the following:
- scalar arguments are fine
  - including 128 bit types, they get passed as two `i64` arguments in both ABIs
- `repr(C)` structs (recursively) wrapping a single scalar argument are fine (unless they have extra padding due to over-alignment attributes)
- all return values are fine

`@bjorn3` `@alexcrichton` `@Manishearth` is that correct?

I am making this a "show up in future compat reports" lint to maximize the chances people become aware of this. OTOH this likely means warnings for most users of Diplomat so maybe we shouldn't do this?

IIUC, wasm-bindgen should be unaffected by this lint as they only pass scalar types as arguments.

Tracking issue: rust-lang#138762
Transition plan blog post: rust-lang/blog.rust-lang.org#1531
bors added a commit to rust-lang-ci/rust that referenced this issue Mar 25, 2025
add FCW to warn about wasm ABI transition

See rust-lang#122532 for context: the "C" ABI on wasm32-unk-unk will change. The goal of this lint is to warn about any function definition and calls whose behavior will be affected by the change. My understanding is the following:
- scalar arguments are fine
  - including 128 bit types, they get passed as two `i64` arguments in both ABIs
- `repr(C)` structs (recursively) wrapping a single scalar argument are fine (unless they have extra padding due to over-alignment attributes)
- all return values are fine

`@bjorn3` `@alexcrichton` `@Manishearth` is that correct?

I am making this a "show up in future compat reports" lint to maximize the chances people become aware of this. OTOH this likely means warnings for most users of Diplomat so maybe we shouldn't do this?

IIUC, wasm-bindgen should be unaffected by this lint as they only pass scalar types as arguments.

Tracking issue: rust-lang#138762
Transition plan blog post: rust-lang/blog.rust-lang.org#1531

try-job: dist-various-2
bors added a commit to rust-lang-ci/rust that referenced this issue Mar 25, 2025
add FCW to warn about wasm ABI transition

See rust-lang#122532 for context: the "C" ABI on wasm32-unk-unk will change. The goal of this lint is to warn about any function definition and calls whose behavior will be affected by the change. My understanding is the following:
- scalar arguments are fine
  - including 128 bit types, they get passed as two `i64` arguments in both ABIs
- `repr(C)` structs (recursively) wrapping a single scalar argument are fine (unless they have extra padding due to over-alignment attributes)
- all return values are fine

`@bjorn3` `@alexcrichton` `@Manishearth` is that correct?

I am making this a "show up in future compat reports" lint to maximize the chances people become aware of this. OTOH this likely means warnings for most users of Diplomat so maybe we shouldn't do this?

IIUC, wasm-bindgen should be unaffected by this lint as they only pass scalar types as arguments.

Tracking issue: rust-lang#138762
Transition plan blog post: rust-lang/blog.rust-lang.org#1531

try-job: dist-various-2
bors added a commit to rust-lang-ci/rust that referenced this issue Mar 25, 2025
add FCW to warn about wasm ABI transition

See rust-lang#122532 for context: the "C" ABI on wasm32-unk-unk will change. The goal of this lint is to warn about any function definition and calls whose behavior will be affected by the change. My understanding is the following:
- scalar arguments are fine
  - including 128 bit types, they get passed as two `i64` arguments in both ABIs
- `repr(C)` structs (recursively) wrapping a single scalar argument are fine (unless they have extra padding due to over-alignment attributes)
- all return values are fine

`@bjorn3` `@alexcrichton` `@Manishearth` is that correct?

I am making this a "show up in future compat reports" lint to maximize the chances people become aware of this. OTOH this likely means warnings for most users of Diplomat so maybe we shouldn't do this?

IIUC, wasm-bindgen should be unaffected by this lint as they only pass scalar types as arguments.

Tracking issue: rust-lang#138762
Transition plan blog post: rust-lang/blog.rust-lang.org#1531

try-job: dist-various-2
bors added a commit to rust-lang-ci/rust that referenced this issue Mar 26, 2025
add FCW to warn about wasm ABI transition

See rust-lang#122532 for context: the "C" ABI on wasm32-unk-unk will change. The goal of this lint is to warn about any function definition and calls whose behavior will be affected by the change. My understanding is the following:
- scalar arguments are fine
  - including 128 bit types, they get passed as two `i64` arguments in both ABIs
- `repr(C)` structs (recursively) wrapping a single scalar argument are fine (unless they have extra padding due to over-alignment attributes)
- all return values are fine

`@bjorn3` `@alexcrichton` `@Manishearth` is that correct?

I am making this a "show up in future compat reports" lint to maximize the chances people become aware of this. OTOH this likely means warnings for most users of Diplomat so maybe we shouldn't do this?

IIUC, wasm-bindgen should be unaffected by this lint as they only pass scalar types as arguments.

Tracking issue: rust-lang#138762
Transition plan blog post: rust-lang/blog.rust-lang.org#1531

try-job: dist-various-2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ABI Area: Concerning the application binary interface (ABI) C-future-incompatibility Category: Future-incompatibility lints C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC O-wasm Target: WASM (WebAssembly), http://webassembly.org/ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants