Re: Which ObjC2.0 features are missing in the latest GCC?

[David Chisnall]

On 26/11/2019 22:43, Fred Kiefer wrote:
> If I understand you correctly your suggestion is that we try to add support in 
> gcc for some of the basic ObjC 2.0 features. That should be doable although the 
> last time I tried I gave up on it. That was right after the Dublin meeting 
> where we had a similar discussion to this one. The gcc people at that time 
> where open to accept patches, but we should not expect too much help coming 
> from their side. The reason I gave up was that at least a new version of the 
> meta information that the compiler creates for the ObjC meta information was 
> needed and I could not figure out a place where to flag that difference.

Please can people stop saying 'Objective-C 2'?  It's a marketing term 
that Apple used briefly and then dropped and has no relationship to any 
real definition of what the language means and does not appear on the 
Apple developer web site at all anymore.

Ian Sandoe was going to work on a better runtime abstraction layer for 
Objective-C in GCC.  He said he'd work on this two years ago, but 
doesn't seem to have made much progress, though he has done a little bit 
of work on improving the state of Apple runtime support.  His plan was 
to delay the runtime-specific lowering to the back end, which would be 
very nice and let LTO do some more interesting things.

Supporting a new ABI is much harder in GCC than Clang because of the 
history.  In GCC, the initial implementation supported only the NeXT 
runtime.  NeXT was forced to release this code via the threat of legal 
action and GCC was forced to merge the code to avoid looking stupid 
after forcing NeXT to release the code.  It was horrible code and if 
NeXT had open sourced it without the threat of legal action, I doubt GCC 
would have accepted it upstream.

Because GCC had the NeXT compiler code but no runtime support, they 
wrote an almost-compatible runtime and littered the code with `if 
(gnu_runtime)` blocks (I think, it might be `if (next_runtime)`.  NeXT / 
Apple never pulled in those changes and so merging from Apple's branch 
was always painful.

In contrast, Clang had no IR generation support when I started working 
on it.  I added an abstract class representing the runtime interfaces 
and a concrete subclass for the GCC and GNUstep runtimes.  Apple then 
maintained this because they were supporting various different runtime 
versions by this point and found the abstraction helpful.

Adding a new GCC-like runtime in clang involved simply creating a new 
subclass of this and overriding the things that had changed.  For GCC, 
it will involve untangling a load of spaghetti code.

It's probably a few months of work for someone with GCC experience to 
add support for the 2.0 ABI, though it's quite tangled with ARC if you 
wan it to actually be useful (for example, ivar metadata contains ARC 
ownership metadata now, which allows various reflection APIs to work 
correctly with ARC).

This is one of the current problems with the 'GNUstep doesn't use ARC, 
but it's fine with other things that do' approach: if you don't use ARC, 
you don't get ARC metadata, so things that use reflection don't work 
quite right from ARC.  You can't use weak properties from GNUstep.  For 
several release on macOS, things like the delegate of various NSView 
subclasses have been weak properties.  This means that modern Cocoa apps 
don't worry about ensuring that the delegate is removed from the view, 
they just rely on the runtime to handle this for them.

In GNUstep, if we wanted to depend on an ARC-supporting runtime but not 
compiler, then we *could* manually write the -setDelegate: and -delegate 
methods to call the relevant ARC functions, but:

 - The ivar would not be __weak and so access via reflection would 
break it.

 - The property metadata would not exist, so anything that depends on 
property metadata would break.

Modern Cocoa APIs are written assuming ARC and involve sublcassing 
classes that are expected to be compiled with ARC.  Over time, the 
work-arounds for the fact that GCC fundamentally does not support the 
same language that Cocoa was designed to work with are increasingly creaky.

TL;DR: Even with support for the new ABI, you still can't implement a 
fully Apple-compatible NSTableView and compile it with GCC.

David