initial implementation of the darwin_objc unstable feature

[jbatez]

Tracking issue: #145496

This feature makes it possible to reference Objective-C classes and selectors using the same ABI used by native Objective-C on Apple/Darwin platforms. Without it, Rust code interacting with Objective-C must resort to loading classes and selectors using costly string-based lookups at runtime. With it, these references can be loaded efficiently at dynamic load time.

r? @tmandry

[rustbot]

r? @lcnr

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

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

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

cc @jdonszelmann

Some changes occurred in compiler/rustc_hir/src/attrs

cc @jdonszelmann

[jdonszelmann]

I looked through the attribute changes and they look good to me. I can't judge the rest. @tmandry feel free to approve in both our names once you agree with the rest :)

[madsmtm]

Looked through it, it seems to match what I tried to do with the objc2 macros those years back (which is not to say that it is correct, I had no idea what I was doing back then).

Also, it would be helpful with more comments, and a few codegen tests - I get why you haven't done that yet, it's bothersome while we're still somewhat discussing what the best approach is.

---

Note: I'm still a bit unsure that this is actually the correct approach going forward, I suspect there might be more value in the future from something like the define_in_every_cgu_used you first proposed?
At the very least we'll also need some way to get protocol references, we might also need metaclass references, and possibly more if we're to support static NSString and support fully statically declared classes.

But I think it's fine to move forwards with this in the current state, then we can always figure that sort of stuff out well before stabilisation.

[jbatez]

... At the very least we'll also need some way to get protocol references, we might also need metaclass references, and possibly more if we're to support static NSString and support fully statically declared classes.

But I think it's fine to move forwards with this in the current state, then we can always figure that sort of stuff out well before stabilisation.

NSString constants were next on my list and should be pretty straightforward. I haven't looked into protocols or metaclasses yet, but I did take a quick peek at static class definitions and, wow, that's a lot more complicated; I'm not personally planning to tackle that any time soon.

[jbatez]

I added tests/codegen-llvm/darwin-objc.rs. In the process, I discovered, at some point, OBJC_CLASSLIST_REFERENCES_$_ and OBJC_SELECTOR_REFERENCES_ were getting optimized away and their initial values were getting used directly. I'm pretty sure this wasn't the case when I originally wrote this months ago. Adding them to llvm.compiler.used (which Clang does as well, fwiw) solved the problem. In the process, I had to convert compiler_used_statics to a RefCell, but I think that's fine.

[bors]

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

[bors]

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

[jbatez]

@tmandry @madsmtm There aren't any more outstanding issues that I'm aware of.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[madsmtm]

Gave it another review after I got around to actually building and playing with it.

The RefCell on compiler_used_statics is fine.

Also, if you could update the PR description to motivate the feature that'd be nice as well (it'll be recorded in Git history).

View changes since this review

[madsmtm]

I would be interested in the following extra assembly tests:

• Using the same class/selector twice in the same codegen unit.
• A test with two codegen units, to ensure that it is the codegen unit that ends up using these that has the references, and that the other doesn't.
• Using one of these in a cross-crate compilation setting, with inlining.
  • Possibly also where the crate that defines the static is compiled as a dylib?
• An assertion that not using any of these means that the Objective-C image/module info isn't output either.

And maybe a "practical" test that uses the macros and tests that things actually links and runs, something like:

//! Run `[NSObject class]` using `core::os::darwin` helpers.
#![feature(darwin_objc)]
use std::mem::transmute;
use std::os::darwin::objc::{Class, SEL, class, selector};

#[link(name = "objc", kind = "dylib")]
unsafe extern "C-unwind" {
    unsafe fn objc_msgSend();
}

#[link(name = "Foundation", kind = "framework")]
unsafe extern "C" {}

fn main() {
    let msg_send_fn = unsafe {
        transmute::<
            unsafe extern "C-unwind" fn(),
            unsafe extern "C-unwind" fn(Class, SEL) -> Class,
        >(objc_msgSend)
    };
    let cls = class!("NSObject");
    let runtime_class = unsafe { msg_send_fn(cls, selector!("class")) };
    assert_eq!(cls, runtime_class);
}

See also the compile tests that objc2 has (I'm not attached to those specifically, but I at least thought those things were interesting to test back when I experimented with it).

[madsmtm]

If you wouldn't mind, I think it'd be useful to have some links to Clang's implementation of the functions you've added in this file - that would make it easier to verify that we're doing things correctly.

[madsmtm]

Also would be nice to document Clang's -fno-objc-msgsend-selector-stubs, which makes verification easier.

[madsmtm]

Testing with:

// clang test_objc_c.m -emit-llvm -S -O -fno-objc-msgsend-selector-stubs
#import <Foundation/Foundation.h>

Class foo(void) {
    return [NSObject foo];
}

And:

// rustc +stage1 test_objc.rs --emit=llvm-ir -O
#![feature(darwin_objc)]
#![crate_type = "lib"]
use std::mem::transmute;
use std::os::darwin::objc::{Class, SEL, class, selector};

#[link(name = "objc", kind = "dylib")]
unsafe extern "C-unwind" {
    unsafe fn objc_msgSend();
}

#[link(name = "Foundation", kind = "framework")]
unsafe extern "C" {}

#[no_mangle]
pub fn foo() -> Class {
    let msg_send_fn = unsafe {
        transmute::<
            unsafe extern "C-unwind" fn(),
            unsafe extern "C-unwind" fn(Class, SEL) -> Class,
        >(objc_msgSend)
    };
    let cls = class!("NSObject");
    unsafe { msg_send_fn(cls, selector!("foo")) }
}

I'm finding the following discrepancies:

• @OBJC_CLASSLIST_REFERENCES_$_ and OBJC_SELECTOR_REFERENCES_ has no_dead_strip in the link section (see also macOS: Why are Objective-C sections marked with no_dead_strip? llvm/llvm-project#114111, I'd be fine with linking to that as to why we don't do that as well).
• @OBJC_SELECTOR_REFERENCES_ has the externally_initialized attribute.
• When loading the @OBJC_SELECTOR_REFERENCES_ symbol, the !invariant.load metadata attribute is used.
• The Rust side uses !noundef a lot (probably fine).

[jbatez]

• I had noticed the no_dead_strip discrepancy as well, found the unresolved LLVM issue you linked, and decided to take objc2's approach and exclude them. But as you note in that issue, "in practice the linker seems to remove it anyhow". So, in the spirit of just matching LLVM when we don't understand, I've added it back.
• Last I checked, the LLVM Rust API we use doesn't currently expose the ability to set externally_initialized. But my understanding is it's only relevant for code with global initializers which Rust doesn't have. But just in-case it matters in the future, I'll take another stab at adding it.
• invariant.load is just an optimization but might be nice to have. I'll look into adding it.

[jbatez]

externally_initialized was easy to add. Looking into invariant.load now.

[madsmtm]

Just calling to attention that this unconditionally loads the value in the static, which I guess is fine, but may also be unnecessarily restrictive?

For example, I can't do:

struct ThreadSafe<T>(T);
unsafe impl<T> Sync for ThreadSafe<T> {}

static CLASSES: ThreadSafe<&[&'static Class]> = ThreadSafe(&[&class!("NSObject"), &class!("NSString")]);

Which I think I'd otherwise be able to do with an extern static.

[jbatez]

That's actually a feature of this design. In one of the Zulip threads, the concern was raised that an extern static with multiple definitions, even if de-deuplicated at static link time, wouldn't be de-duplicated across dylib boundaries. The macro was written such that only the value of the static is accessible and never its identity.

[madsmtm]

Ah, right. Could you document this somewhere in the implementation of the macro? And add a UI test for some of the behaviour that we want to disallow.