Add Swift function call ABI by djc · Pull Request #155815 · rust-lang/rust

djc · 2026-04-26T10:52:12Z

Adds an unstable extern "Swift" ABI behind the abi_swift feature gate, mapping to LLVM's swiftcc calling convention. Cranelift and GCC backends fall back to the platform default since they have no equivalent.

Reimplements #64582 on top of current main. The main objection to it seemed to be that it needed an RFC, but there was pushback (which seems sensible to me) that an RFC could be deferred until stabilization.

I think this needs a tracking issue? Would be happy to write one up if/when there is a consensus that this will be merged.

rustbot · 2026-04-26T10:52:16Z

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

This PR changes rustc_public

cc @oli-obk, @celinval, @ouz-a, @makai410

These commits modify compiler targets.
(See the Target Tier Policy.)

rustbot · 2026-04-26T10:52:18Z

r? @jieyouxu

rustbot has assigned @jieyouxu.
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

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 73 candidates
Random selection from 19 candidates

Adds an unstable `extern "Swift"` ABI behind the `abi_swift` feature gate, mapping to LLVM's `swiftcc` calling convention. Cranelift and GCC backends fall back to the platform default since they have no equivalent.

bjorn3 · 2026-04-26T11:28:06Z


+    /// Swift calling convention, exposed via LLVM's `swiftcc`. Cross-platform
+    /// and not tied to a specific target architecture.
+    Swift,


Do I understand it correctly that the Swift ABI isn't stable yet outside of Apple platforms?

View changes since the review

Yes, I think that's right. How do you think that should affect this PR? Should we only allow this on Apple targets?

Yeah, I think it makes sense to only allow on Apple targets for now.

But on Apple platforms it is stable? We're not chasing a moving target here, are we?

Yes, it's stable on Apple platforms since 2019 and Swift 5:
https://www.swift.org/blog/abi-stability-and-more/

There's a lot of good details in this article:
https://faultlore.com/blah/swift-abi/#resilient-type-layout

There's also Embedded Swift, which has an unstable ABI regardless of platform:
https://docs.swift.org/embedded/documentation/embedded/abi/

bjorn3 · 2026-04-26T11:29:07Z

        CanonAbi::Custom => default_call_conv,

+        // Cranelift has no Swift calling convention; fall back to the platform default.
+        CanonAbi::Swift => default_call_conv,


Please emit an error instead. Silently changing the calling convention is a miscompilations.

View changes since the review

bjorn3 · 2026-04-26T11:29:28Z

        // convention for declaring foreign functions.
        CanonAbi::Custom => return None,
+        // gcc/gccjit does not have anything for Swift's calling convention.
+        CanonAbi::Swift => return None,


Same here

View changes since the review

bjorn3 · 2026-04-26T11:35:24Z

When will arguments be marked as swiftself and swifterror in LLVM IR? Without these it is impossible to call class methods and fallible functions respectively afaik. Also how useful is this without repr(Swift)? Delaying implementation of that to another PR would be fine I think, but I would personally like to see at least a plan for how to soundly implement repr(Swift) given that it breaks the stride=size assumption that is true for all current memory layouts.

djc · 2026-04-26T13:02:25Z

Delaying implementation of that to another PR would be fine I think, but I would personally like to see at least a plan for how to soundly implement repr(Swift) given that it breaks the stride=size assumption that is true for all current memory layouts.

So this is a bit experimental. I plan on looking into all the things (though in my free time, and thus slowly) needed to call into Swift from Rust, but I don't have a plan today. If you want a more concrete plan before merging this, I'd like hear some more detail (in the sense of, maybe a bullet list) of things that need to be done.

bjorn3 · 2026-04-26T13:41:21Z

To be clear, I'm not going to block this PR on figuring out repr(Swift). I'm just a bit worried that we don't figure out repr(Swift) making extern "Swift" not that useful.

By the way I noticed that a question of mine in the previous attempt hadn't been answered yet: #64582 (comment) https://github.com/swiftlang/swift/blob/main/docs/ABI/CallingConventionSummary.rst seems to suggest like the answer to my question is no it doesn't need a separate classify_arg on Apple platforms, but I'm not sure.

jieyouxu · 2026-04-27T06:16:39Z

For something like adding a new ABI, it'd definitely need a RFC accepted prior to stabilization. There are mechanisms to support "land something unstably to gather impl experience to feed RFC design / explore edge cases", in this case I would expect to take the form of a lang experiment. That is, if there is a lang champion happy to champion this.

Asked in #t-lang > Swift call ABI.

madsmtm · 2026-04-27T07:17:13Z

To spell it out explicitly, the primary reason this is interesting is because there's a bunch of platform APIs that are only exposed over the Swift ABI, such as RealityKit and WidgetKit.

Existing solutions need users to write @c wrappers in Swift to expose the functionality over a C ABI, which is inefficient (cross lang LTO is hard) and cumbersome.

jieyouxu

Also, can you please expand on the motivations (in PR description or elsewhere) for adding a new Swift fn call ABI (unstable or not)? There was an earlier PR which this PR revives yes, but we would definitely like to know if the motivations and circumstances have changed since then.

E.g. Mads shared one such motivation in comment above, I'd be curious if you had the same motivations or additional/different ones.

It would also help a lot if the PR description could also be updated to include details like #155815 (comment).

@rustbot author

View changes since this review

rustbot · 2026-04-27T09:19:29Z

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

rustbot assigned jieyouxu Apr 26, 2026

This comment has been minimized.

Sign in to view

Add Swift function call ABI

1fb1a33

Adds an unstable `extern "Swift"` ABI behind the `abi_swift` feature gate, mapping to LLVM's `swiftcc` calling convention. Cranelift and GCC backends fall back to the platform default since they have no equivalent.

djc force-pushed the swift-cc branch from ae29f34 to 1fb1a33 Compare April 26, 2026 11:02

bjorn3 reviewed Apr 26, 2026

View reviewed changes

jieyouxu added the A-ABI Area: Concerning the application binary interface (ABI) label Apr 27, 2026

jieyouxu reviewed Apr 27, 2026

View reviewed changes

rustbot 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-review Status: Awaiting review from the assignee but also interested parties. labels Apr 27, 2026

Uh oh!

Conversation

djc commented Apr 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Apr 26, 2026

Uh oh!

rustbot commented Apr 26, 2026

Uh oh!

This comment has been minimized.

bjorn3 Apr 26, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

djc Apr 26, 2026

Choose a reason for hiding this comment

Uh oh!

bjorn3 Apr 26, 2026

Choose a reason for hiding this comment

Uh oh!

RalfJung Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

teor2345 Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

bjorn3 Apr 26, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bjorn3 Apr 26, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bjorn3 commented Apr 26, 2026

Uh oh!

djc commented Apr 26, 2026

Uh oh!

bjorn3 commented Apr 26, 2026

Uh oh!

jieyouxu commented Apr 27, 2026

Uh oh!

madsmtm commented Apr 27, 2026

Uh oh!

jieyouxu left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustbot commented Apr 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

djc commented Apr 26, 2026 •

edited

Loading

bjorn3 Apr 26, 2026 •

edited by rustbot

Loading

bjorn3 Apr 26, 2026 •

edited by rustbot

Loading

bjorn3 Apr 26, 2026 •

edited by rustbot

Loading

jieyouxu left a comment •

edited

Loading