[WIP] Introduce repr(Swift)

[Lancelotbronner]

Adds the repr(Swift) attribute, allowing direct representation of Swift structs.

Since rebasing on the latest main it probably doesn't compile anymore.
I'd like to gauge interest to see if it's worth my time to continue this.

• I did not use an LLM to create a change in this PR.
• I used an LLM to create a change in this PR, and I have explained below how it was used.

[rustbot]

rustc_codegen_gcc is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_gcc instead.

cc @antoyo, @GuillaumeGomez

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann, @JonathanBrouwer

rustc_codegen_cranelift is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_cranelift instead.

cc @bjorn3

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

This PR changes rustc_public

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

⚠️ #[rustc_intrinsic_const_stable_indirect] controls whether intrinsics can be exposed to stable const
code; adding it needs t-lang approval.

cc @rust-lang/wg-const-eval

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred in compiler/rustc_hir/src/attrs

cc @jdonszelmann, @JonathanBrouwer

[rustbot]

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @JohnTitor (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: libs
• libs expanded to 12 candidates
• Random selection from JohnTitor, Mark-Simulacrum, clarfonthey, nia-e

[RalfJung]

Something as fundamental as adding a new kind of size will at the very least need an MCP if it's something that only ever matters internally to compiler devs, or an RFC if it is relevant to people writing (unsafe) Rust code.

View changes since the review

[JonathanBrouwer]

Indeed, and furthermore the attribute change requires a T-lang RFC, see https://github.com/rust-lang/rfcs#what-the-process-is

If you'd only like to like to gauge interest without writing a full RFC immediately, I'd recommend opening a zulip thread explaining your idea

@rustbot author

[jieyouxu]

cf. #156481, but that was only a lang experiment about swift function call ABI, not repr(swift).

[jieyouxu]

In particular, any repr(Swift) ABI attempts really ought to address #155815 (comment) and #155815 (comment):

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.

[...]

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.

[Lancelotbronner]

Indeed, and furthermore the attribute change requires a T-lang RFC, see https://github.com/rust-lang/rfcs#what-the-process-is

If you'd only like to like to gauge interest without writing a full RFC immediately, I'd recommend opening a zulip thread explaining your idea

@rustbot author

I had one here:
https://rust-lang.zulipchat.com/#narrow/channel/427678-t-lang.2Finterop/topic/Interop.20with.20Swift.2C.20how.20to.20implement.20type.20layout.3F/with/615343099

[RalfJung]

Yes, and you were given a lot of questions there that need a coherent answer and buy-in from the relevant team(s) before we can begin landing code changes here. You are proposing a very deep-cutting change here, we're not doing such changes without some planning.
I can't tell immediately whether your goal is to expose a new kind of "size" as something Rust programmers can see and need to deal with (needs RFC) or just a new internal representation of types in the compiler (needs MCP).

[rustbot]

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

[rustbot]

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

[Lancelotbronner]

I've fixed the build so I can actually run my test ground at https://github.com/Lancelotbronner/rust-swift-interop.

I'll do some more research on how I can deal with the questions, I'd personally like it to remain internal but I don't know if that's feasible.

[rust-log-analyzer]

The job pr-check-2 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

    |         ^^^^^^^^^^^^^^^ not a unit struct, unit variant or constant
    |
help: the struct variant's field is being ignored
    |
257 |         CanonAbi::Swift { tail: _ } => {
    |                         +++++++++++

For more information about this error, try `rustc --explain E0533`.
[RUSTC-TIMING] rustc_codegen_gcc test:false 1.154
error: could not compile `rustc_codegen_gcc` (lib) due to 1 previous error

[rust-bors]

☔ The latest upstream changes (presumably #160761) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.