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

try-job: *apple*

[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.

[jbatez]

I added a lot of tests. Let me know if there's any other tests you'd like to see.

I took a peek at adding invariant.load at the load sites, but it looked like to me that the places where we generate the load instruction are pretty far abstracted from having any metadata about the static that we're loading from. And there are many different code paths that lead to these, so plumbing that through looks like more trouble than it's worth at this time.

[jbatez]

@madsmtm Is there anything else you'd like me to address?

[madsmtm]

I like the objc_abi_version method you added, that makes things easier to read.

invariant.load

That's fine, and I agree it seems like it's just an optimization anyhow (though possibly an important one for e.g. loop-invariant code motion).

---

I think I'm comfortable enough with the compiler parts to approve that (so r=me for that part).

I'm a bit unsure how we do this process-wise, but I think this needs a t-libs reviewer as well for the library parts? (even though that part is relatively minimal) And if I'm reading the docs right, I think @tmandry needs to start a lang FCP.

Let's see how the tests fare in the meantime:
@bors try jobs=*apple*

View changes since this review

[madsmtm]

@bors try

[rust-bors]

💔 Test for 19b63b3 failed: CI. Failed jobs:

• try - aarch64-apple (web logs, extended logs)

[madsmtm]

@bors try

[rust-bors]

☀️ Try build successful (CI)
Build commit: df197fd (df197fd81e0470fad94526495a49b449e35ab96d, parent: 71289c378d0a406a4f537fe4001282d19362931f)

[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.

[jbatez]

@bors try

[rust-bors]

@jbatez: 🔑 Insufficient privileges: not in try users

[madsmtm]

@bors try

[rust-bors]

⌛ Trying commit 0c1dc47 with merge 3652b48…

To cancel the try build, run the command @bors try cancel.