initial implementation of the darwin_objc unstable feature #145660

jbatez · 2025-08-20T13:18:34Z

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*
try-job: x86_64-gnu-nopt

rustbot · 2025-08-20T13:18:39Z

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 · 2025-08-20T13:18:43Z

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 · 2025-08-20T15:59:29Z

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.

compiler/rustc_attr_parsing/src/attributes/codegen_attrs.rs

library/core/src/os/mod.rs

compiler/rustc_hir/src/attrs/encode_cross_crate.rs

compiler/rustc_feature/src/builtin_attrs.rs

compiler/rustc_codegen_llvm/src/consts.rs

compiler/rustc_codegen_llvm/src/base.rs

compiler/rustc_codegen_llvm/src/consts.rs

jbatez · 2025-08-21T00:50:52Z

... 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 · 2025-08-21T16:30:04Z

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 · 2025-08-22T03:22:22Z

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

madsmtm · 2025-09-13T14:50:49Z

Ah, has to be separate lines:
@bors try

initial implementation of the darwin_objc unstable feature try-job: `*apple*` try-job: `x86_64-gnu-nopt`

rust-bors · 2025-09-13T17:13:59Z

☀️ Try build successful (CI)
Build commit: d8a9c1f (d8a9c1f3d7ad1c7fe0f3f8c3db489d49bb139d43, parent: b50f345a2f3f49764024cabc30ef99e15c0240f7)

madsmtm · 2025-09-13T20:02:50Z

@jbatez could you squash? Then I'll add it to the queue again.

jbatez · 2025-09-13T21:01:45Z

@madsmtm done.

rustbot · 2025-09-13T23:06:51Z

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 · 2025-09-17T03:03:12Z

Thanks!

@bors r=jdonszelmann,madsmtm,tmandry

bors · 2025-09-17T03:03:14Z

📌 Commit 1ebf69d has been approved by jdonszelmann,madsmtm,tmandry

It is now in the queue for this repository.

madsmtm · 2025-09-17T03:04:45Z

@bors rollup=iffy

Reason: It failed in rollup before, there might be other overspecified test cases in here.

…,madsmtm,tmandry initial implementation of the darwin_objc unstable feature Tracking issue: rust-lang#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*` try-job: `x86_64-gnu-nopt`

…,madsmtm,tmandry initial implementation of the darwin_objc unstable feature Tracking issue: rust-lang#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*` try-job: `x86_64-gnu-nopt`

Rollup of 14 pull requests Successful merges: - #142807 (libtest: expose --fail-fast as an unstable command-line option) - #144871 (Stabilize `btree_entry_insert` feature) - #145071 (Update the minimum external LLVM to 20) - #145181 (remove FIXME block from `has_significant_drop`, it never encounters inference variables) - #145660 (initial implementation of the darwin_objc unstable feature) - #145838 (don't apply temporary lifetime extension rules to non-extended `super let`) - #146259 (Suggest removing Box::new instead of unboxing it) - #146410 (Iterator repeat: no infinite loop for `last` and `count`) - #146460 (Add tidy readme) - #146552 (StateTransform: Do not renumber resume local.) - #146564 (Remove Rvalue::Len again.) - #146581 (Detect attempt to use var-args in closure) - #146588 (tests/run-make: Update list of statically linked musl targets) - #146631 (cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 3)) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #145660 - jbatez:darwin_objc, r=jdonszelmann,madsmtm,tmandry initial implementation of the darwin_objc unstable feature 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*` try-job: `x86_64-gnu-nopt`

rustbot assigned lcnr Aug 20, 2025

rustbot assigned tmandry and unassigned lcnr Aug 20, 2025

jbatez mentioned this pull request Aug 16, 2025

Tracking Issue for darwin_objc #145496

Open

10 tasks