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. This is only allowed (a) for is_darwin_like targets, since the ABI is only stable for those platforms and (b) with the LLVM backend, since the other backends don't support it.

Current approaches to interoperability with Swift lower to Objective-C (or require a Swift stub exposing a C ABI), but that is an optional mapping on the Swift side that some newer Apple frameworks omit. It would be great to be able to more directly/natively be able to call into Swift code directly via its stable API (on Apple platforms at least).

Reimplements #64582 on top of current main. The main objection to the previous PR 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

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.

djc · 2026-05-02T08:02:48Z

@rustbot ready

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.

rustbot assigned jieyouxu Apr 26, 2026

This comment has been minimized.

Sign in to view

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

Comment thread compiler/rustc_abi/src/canon_abi.rs

bjorn3 reviewed Apr 26, 2026

View reviewed changes

Comment thread compiler/rustc_codegen_cranelift/src/abi/mod.rs Outdated

bjorn3 reviewed Apr 26, 2026

View reviewed changes

Comment thread compiler/rustc_codegen_gcc/src/abi.rs Outdated

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

djc force-pushed the swift-cc branch from 1fb1a33 to f8bd675 Compare May 2, 2026 08:02

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 May 2, 2026

This comment has been minimized.

Sign in to view

djc force-pushed the swift-cc branch from f8bd675 to 3236a13 Compare May 2, 2026 09:10

Add Swift function call ABI

c528852

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 3236a13 to c528852 Compare May 2, 2026 09:26

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.

Uh oh!

Uh oh!

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!

djc commented May 2, 2026

Uh oh!

This comment has been minimized.

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

djc commented Apr 26, 2026 •

edited

Loading

jieyouxu left a comment •

edited

Loading