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.

[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

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

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.