RFC: Deprecating obsolete ObjC features

There is a number of presumably obsolete ObjC features that Clang keeps in-tree, namely fragile runtime (ABI) and GC support. I propose:

  1. To deprecate -fobjc-runtime=macosx-fragile, -fobjc-subscripting-legacy-runtime, and -rewrite-legacy-objc in 18 release, remove in 19.
  2. To deprecate -fobjc-gc, -fobjc-gc-only, -print-ivar-layout in 18 release, remove in 19.
  3. For i386 macOS triples, which currently default to macosx-fragile runtime, issue a diagnostic that runtime should be explicitly specified. Make it a warning in 18 release (possibly combine with the deprecation warning), promote to an error in 19.

This RFC is a result of a discussion happened in [analyzer] Bugzilla Database Cleanup Policy. As mentioned there, Apple is no longer interested in both fragile runtime and GC. GNU runtime removed GC support 7 months ago.

macOS 10.14 was the last one to support i386 apps, but it reached end of life in late 2021.

This is my first time deprecating anything in Clang, and my first time working with ObjC. Please let me know if I missed anything.

CC @rjmccall @davidchisnall


The plan sounds reasonable to me, but I don’t have any stake in it. @ldionne might also know who to ask.

We all love clean ups, but I have very little knowledge of Objective-C. I pinged the appropriate people over here who know more about Objective-C, the state of support of various features, etc :-).

Support for Darwin PowerPC was removed from Clang and LLVM back in 2020. Any remaining code which purports to support macOS PPC is dead and can be removed immediately.

1 Like

Thank you! I updated the initial post, removing PPC, because it wasn’t the focus in the first place, and now it’s clear that removing those parts doesn’t need to go through RFC process

Just to be clear: this would effectively remove support for building Objective-C code on i386 macOS. I don’t think there’s any point in suggesting users target the non-fragile ABI on i386 macOS, because that’s not the ABI the system provides.

Anyways, it seems like if we’re going to remove macosx-fragile, we’d get the most benefit by dropping support for non-fragile objc ABIs entirely. That implies also de-supporting the “gcc” runtime. I think most usage of Objective-C on non-Apple platforms moved from the “gcc” runtime to the “gnustep” libobjc2 long ago, but I’m not certain about that. Does anyone actually still use the support for the “gcc” runtime? @davidchisnall maybe you know?

There are still users of the GCC runtime, though I’m not sure who is using it with clang.

I don’t think there’s much synergistic to be gained from dropping support for fragile runtimes as a class. The ObjC support in clang is almost all either totally independent of the target runtime (e.g. Sema) or totally specific to it (e.g. message-send emission). I’m sure there’s some code specific to the GCC runtime that we could remove if we dropped support for it, but because it’s a different runtime, not specifically because it’s fragile.

Maybe a few tests?