Skip to content

Don't warn about v128 in wasm ABI transition #139809

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

Merged
merged 1 commit into from
Apr 24, 2025

Conversation

alexcrichton
Copy link
Member

@alexcrichton alexcrichton commented Apr 14, 2025

The -Zwasm-c-abi=spec mode of extern "C" does not actually change the meaning of v128 meaning that the FCW lint firing is a false positive.

cc #138762 (comment)

@rustbot
Copy link
Collaborator

rustbot commented Apr 14, 2025

r? @compiler-errors

rustbot has assigned @compiler-errors.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 14, 2025
@alexcrichton
Copy link
Member Author

Like with #139498, I'm going to beta-nominate this as the affected warning is currently present on beta.

@alexcrichton alexcrichton added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Apr 14, 2025
@jieyouxu jieyouxu added the O-wasm Target: WASM (WebAssembly), http://webassembly.org/ label Apr 17, 2025
@jieyouxu
Copy link
Member

jieyouxu commented Apr 17, 2025

Hi @alexcrichton, could you elaborate on what you mean by "other warning if necessary"?

Based on the reported code snippet in #138762 (comment) but with #![allow(wasm_c_abi)]

#![allow(wasm_c_abi)]
use std::arch::wasm32::{
    v128,
    v128_any_true};

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

I'm not observing another warning, am I missing something? Or rather, could you slightly elaborate on why v128 specifically is okay for wasm_c_abi?

@alexcrichton
Copy link
Member Author

Oh sure yeah, this code:

use std::arch::wasm32::*;

#[unsafe(no_mangle)]
#[target_feature(enable = "simd128")]
pub extern "C" fn foo(_: v128) {}

currently yields two warnings

warning: `extern` fn uses type `std::arch::wasm32::v128`, which is not FFI-safe
 --> <source>:5:26
  |
5 | pub extern "C" fn foo(_: v128) {}
  |                          ^^^^ not FFI-safe
  |
  = help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct
  = note: this struct has unspecified layout
  = note: `#[warn(improper_ctypes_definitions)]` on by default

warning: this function definition involves an argument of type `std::arch::wasm32::v128` which is affected by the wasm ABI transition
 --> <source>:5:1
  |
5 | pub extern "C" fn foo(_: v128) {}
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #138762 <https://github.com/rust-lang/rust/issues/138762>
  = help: the "C" ABI Rust uses on wasm32-unknown-unknown will change to align with the standard "C" ABI for this target
  = note: `#[warn(wasm_c_abi)]` on by default

This PR is just addressing the second one which shows up transitively through crates, not the first one which I'm not changing here.

@jieyouxu
Copy link
Member

This PR is just addressing the second one which shows up transitively through crates, not the first one which I'm not changing here.

Thanks, that's what I was missing

Copy link
Member

@jieyouxu jieyouxu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

@jieyouxu
Copy link
Member

@bors r+ rollup

@bors
Copy link
Collaborator

bors commented Apr 17, 2025

📌 Commit 38667e5 has been approved by jieyouxu

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 17, 2025
@jieyouxu jieyouxu assigned jieyouxu and unassigned compiler-errors Apr 17, 2025
@RalfJung
Copy link
Member

improper_ctypes warns about so many things that are needed in practice and generally work fine, chances are people have it allowed... but I guess then they don't get to complain if we change the ABI.^^

@jieyouxu
Copy link
Member

improper_ctypes warns about so many things that are needed in practice and generally work fine, chances are people have it allowed... but I guess then they don't get to complain if we change the ABI.^^

I suppose we can call this out in relnotes?

@jieyouxu
Copy link
Member

Unsettled discussion on trade-offs
@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Apr 17, 2025
@RalfJung
Copy link
Member

RalfJung commented Apr 17, 2025

We have a blogpost about the transition, and the relnotes (I expect) will link there. So there are other ways people can learn about this.

But, also note that improper_ctypes is not an FCW so unlike this warning, it will not show up for dependencies. If my dependency passes v128 over a wasm ABI, then with this PR I will get no warning.

@alexcrichton
Copy link
Member Author

Sorry I'm a bit confused, what's being asked for here?

The v128 type is already ABI-unstable in that it generates a compiler warning. The wasm C ABI transition doesn't affect that. This PR is instead fixing a bug where when using std::arch::wasm32::* intrinsics they're generating a warning about the C ABI transition which is a false positive. Given that I'm not certain what's being asked for to be changed here?

@RalfJung
Copy link
Member

RalfJung commented Apr 17, 2025

I'm slightly concerned some crate could be passing v128, either allowing or ignoring the lint, as that lint has plenty of false positives so it is often being allowed. Only the author of the crate would see the lint anyway. Some user of that crate would see this FCW, however, thus warning them that they can be affected by this transition.

Can you point at the declaration of such an intrinsic that causes a warning? Why would an intrinsic use the "C" ABI? Usually they do not.

@hanna-kruppe
Copy link
Contributor

The intrinsics that get the warning are LLVM intrinsics, not Rust intrinsics, which stdarch declares as extern "C" here: https://github.com/rust-lang/stdarch/blob/7ae34fad5e3c55c1ff150121872d9ee5f4d56a94/crates/core_arch/src/wasm32/simd128.rs#L76

@jieyouxu
Copy link
Member

r? RalfJung (since you have concerns)

@rustbot rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Apr 22, 2025
@rustbot
Copy link
Collaborator

rustbot commented Apr 22, 2025

Reminder, once the PR becomes ready for a review, use @rustbot ready.

@Amanieu
Copy link
Member

Amanieu commented Apr 22, 2025

Ah never mind, the compiler-builtins PR has landed. Any chance we could get a release so we can check whether that fixes the underlying issue here?

You mean stdarch? There's no release, you just need to update the submodule.

This has other warnings if necessary and doesn't need extra warnings
from this FCW.

cc rust-lang#138762
@alexcrichton
Copy link
Member Author

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 22, 2025
@RalfJung
Copy link
Member

You mean stdarch? There's no release, you just need to update the submodule.

Ah sorry, I mixed up the crates.

@RalfJung
Copy link
Member

@alexcrichton thanks, and sorry for the delay!
@bors r+

@bors
Copy link
Collaborator

bors commented Apr 23, 2025

📌 Commit 19e44d4 has been approved by RalfJung

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 23, 2025
Zalathar added a commit to Zalathar/rust that referenced this pull request Apr 24, 2025
…fJung

Don't warn about `v128` in wasm ABI transition

The `-Zwasm-c-abi=spec` mode of `extern "C"` does not actually change the meaning of `v128`  meaning that the FCW lint firing is a false positive.

cc rust-lang#138762 (comment)
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 24, 2025
Rollup of 23 pull requests

Successful merges:

 - rust-lang#139261 (mitigate MSVC alignment issue on x86-32)
 - rust-lang#139307 (std: Add performance warnings to HashMap::get_disjoint_mut)
 - rust-lang#139700 (Autodiff flags)
 - rust-lang#139752 (set subsections_via_symbols for ld64 helper sections)
 - rust-lang#139809 (Don't warn about `v128` in wasm ABI transition)
 - rust-lang#139852 (StableMIR: Implement `CompilerInterface`)
 - rust-lang#139945 (Extend HIR to track the source and syntax of a lifetime)
 - rust-lang#140028 (`deref_patterns`: support string and byte string literals in explicit `deref!("...")` patterns)
 - rust-lang#140139 (rustc_target: Adjust RISC-V feature implication)
 - rust-lang#140143 (Move `sys::pal::os::Env` into `sys::env`)
 - rust-lang#140148 (CI: use aws codebuild for job dist-arm-linux)
 - rust-lang#140150 (fix MAX_EXP and MIN_EXP docs)
 - rust-lang#140172 (Make algebraic functions into `const fn` items.)
 - rust-lang#140177 ([compiletest] Parallelize test discovery)
 - rust-lang#140181 (Remove `synstructure::Structure::underscore_const` calls.)
 - rust-lang#140184 (Update doc of cygwin target)
 - rust-lang#140186 (Rename `compute_x` methods)
 - rust-lang#140187 ([AIX] Handle AIX dynamic library extensions within c-link-to-rust-dylib run-make test)
 - rust-lang#140191 (Remove git repository from git config)
 - rust-lang#140194 (minicore: Have `//@ add-core-stubs` also imply `-Cforce-unwind-tables=yes`)
 - rust-lang#140195 (triagebot: label minicore changes w/ `A-test-infra-minicore` and ping jieyouxu on changes)
 - rust-lang#140202 (Make #![feature(let_chains)] bootstrap conditional in compiler/)
 - rust-lang#140214 (Remove comment about handling non-global where bounds with corresponding projection)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 24, 2025
…iaskrgr

Rollup of 9 pull requests

Successful merges:

 - rust-lang#134446 (Stabilize the `cell_update` feature)
 - rust-lang#139307 (std: Add performance warnings to HashMap::get_disjoint_mut)
 - rust-lang#139450 (Impl new API `std::os::unix::fs::mkfifo` under feature `unix_fifo`)
 - rust-lang#139809 (Don't warn about `v128` in wasm ABI transition)
 - rust-lang#139852 (StableMIR: Implement `CompilerInterface`)
 - rust-lang#139945 (Extend HIR to track the source and syntax of a lifetime)
 - rust-lang#140028 (`deref_patterns`: support string and byte string literals in explicit `deref!("...")` patterns)
 - rust-lang#140181 (Remove `synstructure::Structure::underscore_const` calls.)
 - rust-lang#140232 (Remove unnecessary clones)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 32b2428 into rust-lang:master Apr 24, 2025
6 checks passed
@rustbot rustbot added this to the 1.88.0 milestone Apr 24, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Apr 24, 2025
Rollup merge of rust-lang#139809 - alexcrichton:wasm-simd-safe, r=RalfJung

Don't warn about `v128` in wasm ABI transition

The `-Zwasm-c-abi=spec` mode of `extern "C"` does not actually change the meaning of `v128`  meaning that the FCW lint firing is a false positive.

cc rust-lang#138762 (comment)
@jieyouxu
Copy link
Member

This was discussed in today's compiler triage meeting. Beta backport was approved. Thanks!

@rustbot label: +beta-accepted

@rustbot rustbot added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Apr 24, 2025
@cuviper cuviper mentioned this pull request Apr 24, 2025
@cuviper cuviper modified the milestones: 1.88.0, 1.87.0 Apr 24, 2025
@cuviper cuviper removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Apr 24, 2025
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 26, 2025
[beta] backports

- Do not mix normalized and unnormalized caller bounds when constructing param-env for `receiver_is_dispatchable` rust-lang#138941
- Ignore zero-sized types in wasm future-compat warning rust-lang#139498
- Don't warn about `v128` in wasm ABI transition rust-lang#139809
- Revert overzealous parse recovery for single colons in paths rust-lang#140228

r? cuviper
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 26, 2025
[beta] backports

- Do not mix normalized and unnormalized caller bounds when constructing param-env for `receiver_is_dispatchable` rust-lang#138941
- Ignore zero-sized types in wasm future-compat warning rust-lang#139498
- Don't warn about `v128` in wasm ABI transition rust-lang#139809
- Revert overzealous parse recovery for single colons in paths rust-lang#140228

r? cuviper
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 26, 2025
[beta] backports

- Do not mix normalized and unnormalized caller bounds when constructing param-env for `receiver_is_dispatchable` rust-lang#138941
- Ignore zero-sized types in wasm future-compat warning rust-lang#139498
- Don't warn about `v128` in wasm ABI transition rust-lang#139809
- Revert overzealous parse recovery for single colons in paths rust-lang#140228

r? cuviper
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta-accepted Accepted for backporting to the compiler in the beta channel. O-wasm Target: WASM (WebAssembly), http://webassembly.org/ S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants