-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
add FCW to warn about wasm ABI transition #138601
base: master
Are you sure you want to change the base?
Conversation
r? @wesleywiser rustbot has assigned @wesleywiser. Use |
LL | pub extern "C" fn my_fun(_x: MyType) {} | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
| | ||
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not technically correct that this will become a hard error (we'll just do the ABI switch), but I don't know how to make an FCW that does not have this message...
This comment has been minimized.
This comment has been minimized.
That doesn't seem to be necessary. Both the old abi and new abi pass it as two i64 arguments. |
Re: i128, we just had an ABI break (independent of -Zwasm-c-abi) in 1.85 but it only changed alignment not the by-value ABI I believe #134165 |
aed14e4
to
fe72062
Compare
This comment has been minimized.
This comment has been minimized.
Honestly I'm not actually sure. The ABI bits have always been a black box to me and I don't feel confident that I would be able to enumerate the list of differences between That being said what you listed matches my rough understanding. I mostly want to clarify in that I do not have certainty on the exhaustiveness of my understanding. Would it be possible to "run both ABIs and look for a difference"? That'd help make me more confident in the exhaustiveness of the check, but I'm not sure if that's possible given the structure of the code. What I can perhaps clarify is that the "official definition" is this for params/results. I'm not knowledgable enough of rustc ABI internals to diff that with what the previous behavior was myself though. |
"detects code relying on rustc's non-spec-compliant wasm C ABI", | ||
@future_incompatible = FutureIncompatibleInfo { | ||
reason: FutureIncompatibilityReason::FutureReleaseErrorReportInDeps, | ||
reference: "issue #122532 <https://github.com/rust-lang/rust/issues/122532>", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before landing this I think it might be best to open a fresh issue here. This one's got ~100 comments and is quite old. I'm happy to open a fresh issue to fill in here once we're more settled on a final transition plan.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's 100 comments, and it is from May last year. But sure happy to update this to another issue number if you tell me the number :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think we should have a separate issue that helps talk about mitigation strategies.
No, it's not possible unfortunately. The entire issue is that the legacy ABI relies on LLVM details rustc has no knowledge about, and on rustc_codegen_llvm details the rest of rustc has no knowledge about. |
Ok thanks for clarifying, in that case I think we can mitigate that by (a) adding appropriate wording to the blog post about this change and perhaps (b) calling out in the release notes for the next release of Rust "hey things are changing in wasm go read this blog post for more info". Basically just doing our best to raise awareness and get folks testing out |
Some changes occurred in compiler/rustc_codegen_ssa These commits modify compiler targets. |
I've filed #138762 as a landing page for this lint |
Thanks, I have updated the PR to link to that issue. The PR should be good to go then? Nowhere in the blog post or the tracking issue do we mention that |
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#138601 (add FCW to warn about wasm ABI transition) - rust-lang#138662 (Implement some basics in UEFI fs) - rust-lang#138800 (remove remnants of const_box feature) - rust-lang#138821 (match lowering cleanup: remove unused unsizing logic from `non_scalar_compare`) - rust-lang#138864 (Rework `--print` options documentation) - rust-lang#138868 (Add do_not_recommend typo help) - rust-lang#138882 (`with_scope` is only ever used for ast modules) r? `@ghost` `@rustbot` modify labels: rollup
@bors r- rollup=iffy |
Eh, but I have allowed the lint for the entire module, why does it still trigger? |
Locally a wasm32-unknown-unknown build of proc_macro works just fine... wtf. @bors try |
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
⌛ Trying commit 61e24e6 with merge cb87fb8ade9ebde8ee368f236e61795631f523a2... |
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
Yeah same error. No idea what is happening.
|
@bors try |
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
⌛ Trying commit 782a797 with merge fde8c7793c0fdf859d230a4b86205a9495d2965e... |
@bors try |
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
⌛ Trying commit e88c49c with merge c19c3fbac0c3230987fe8ccfcb40573cd8ef9b14... |
r? @alexcrichton |
☀️ Try build successful - checks-actions |
See #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:
i64
arguments in both ABIsrepr(C)
structs (recursively) wrapping a single scalar argument are fine (unless they have extra padding due to over-alignment attributes)@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: #138762
Transition plan blog post: rust-lang/blog.rust-lang.org#1531
try-job: dist-various-2