RFC: Deprecating obsolete ObjC features

Clang Frontend
1

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

2 Likes
2

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

3

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 :-).

4

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
5

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

6

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?

7

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

8

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?

9

I was thinking that there’s a bunch of predicates in ObjCRuntime.h which would return a constant value if GCC was removed in addition to FragileMacOSX. On second look, guess it’s not that much really, just isNonFragile isFragile allowsSizeofAlignof allowsARC allowsPointerArithmetic isSubscriptPointerArithmetic. Not much code is controlled by those predicates, and the question is moot anyways, if the “GCC” runtime hasn’t actually been superseded in usage by the “GNUstep” runtime.

So, yea, we can just forget about the suggestion to drop support for the “gcc” runtime. :slight_smile:

1 Like