objective-c support

[dotcarmen]

Unlike C++, Objective-C is a strict superset of C that is supported by GCC and Clang. Since these features are purely additive, I believe it'd be beneficial to support Objective-C in Aro - though if it's determined out of scope, I'd start and maintain a fork of Aro that supports Objective-C. My primary motivation for this feature is to use Aro to generate bindings to Objective-C frameworks using my objc bindings library.

I propose the following plan for Objective-C support in arocc. To match Clang behavior, Objective-C support will automatically be enabled on Darwin targets, and will be supported on other platforms with the -ObjC flag.

Note that lots of Objective-C usage relies on the Blocks C extension, which I've already started working on. I believe it makes sense to automatically toggle Blocks support when Objective-C support is enabled, but I'm not yet sure if that happens on non-Darwin platforms.

Initially, Objective-C support will be focused on Darwin targets by Clang emulation. Once this list of features is complete, support for GCC emulation (which uses GNU Step and may have some variation in compiler output) and potentially non-emulated output can be tackled in parallel with bug squashing and other missing features.

This list is mostly "vibes-based" based on my research into the Objective-C runtime for my bindings library. The ordering is a guideline, not a rule, for implementation, and some features may be un/intentionally excluded. However, this set of features should cover the majority of Objective-C programs.

• __OBJC__, OBJC_TYPES_DEFINED, __OBJC_BOOL_IS_BOOL, OBJC_API_VERSION, OBJC_NO_GC
  • OBJC_TYPES_DEFINED requires builtin definitions for Class, Method, SEL, Object, and more.
  • __OBJC_BOOL_IS_BOOL indicates using the builtin bool type for the objective-c BOOL type.
    • __has_feature(objc_bool) isn't required, since the fallback is fine for arocc usage.
  • OBJC_API_VERSION initially will always be set to 2
    • Support for the legacy api version 0 can be added in the future, but since it's long obsolete, I don't see much value in supporting it immediately.
  • since objc ARC has been the standard for a long time, I also don't see value in immediately supporting objc garbage collection
• #import and @import
  • #import is the same as #include but eliminates the need for include guards
  • @import is the same as #import but allows for bare identifiers to import the main framework header - ie #import <Foundation/Foundation.h> -> @import Foundation;
    • turns out, @import enables a clang feature called modules, which is a caching strategy that clang uses. more investigation needed
• id type
  • id is essentially void *, but can be coerced to from any pointer type
  • id can also be typed, eg id<NSObject> is a pointer to an object of a class that conforms to the NSObject protocol
• @selector. This returns a *SEL for the raw selector AST.
• @protocol, method signatures
  • This requires generating hooks for protocol construction. I'm not yet sure how/when these hooks are called in Clang or GCC outputs
• @property
  • This requires a limited set of property attributes (readonly, getter, setter, copy) to cover the majority of cases
• @interface
  • This requires generating hooks for class construction. I'm not yet sure how/when these hooks are called in Clang or GCC outputs, nor am I sure how class construction is different between @interface and @implementation declarations.
• @available
  • As far as I can tell, this is only available/used on Darwin platforms, and is used for OS version checks
• message-passing (ie [foo bar] and [foo bar:3])
  • These usually get lowered to a call to some variant of objc_msgSend, which must be cast to an appropriate type before calling.
• objective-c literal strings, chars, and numbers. bools are automatically handled by objc headers.
  • I believe these are implemented by sending a message to NSString and NSNumber, needs verification though
• @implementation, @synthesize
  • This is necessary for parsing Objective-C implementation files.
  • This also requires parsing and lowering method implementations and registering them in the class construction hook.
• Objective-C ARC support (@autoreleasepool and various lowering modifications using eg objc_retain and objc_release)

Note that I don't believe it makes sense to implement libobjc in arocc - instead, the compiler should rely on the library being available as a dynamic library on the target system.

edit: similar to the comment in #971 (comment), it's easiest to test objective-c lowering on Darwin platforms. since aro doesn't currently support lowering to Darwin platforms, it doesn't make sense to implement lowering objective-c until either aro gains support for lowering to Darwin platforms, or GNU Step support is added (since it's the only runtime i'm aware of that support x86_64-linux, the only target aro lowers to)

[Vexu]

I'm in favor of supporting more C language families in both Aro and translate-c, I just don't think I'm going to be working on them much.

[dotcarmen]

I plan on contributing at least until i can write my generator using aro :) i'll try to keep the ball rolling, but with ADHD and since i'm doing this in my free time, I can't promise I'll take this all the way across the line, at least not quickly 😅

[megaNour]

Hello, would simd fit that list ?
That would enable translating vectors like vector_float2 and so on.

If you try to translate such a type, you should find a result like below, which result from guards in <macos_sdk_path>/usr/include/simd/vector_types.h, which calls simd/base.h and so on:

pub const SIMD_VECTOR_TYPES = "";
pub const SIMD_BASE = "";
pub const SIMD_COMPILER_HAS_REQUIRED_FEATURES = @as(c_int, 0);

[Vexu]

That does not seem to have anything to do with objective-c and instead depends on ext_vector_type and overloadable attributes.

[megaNour]

ah sorry, that's a foreign domain to me. I'm really poking in the dark.
But the issue is worth raising.

I could make a distinct one like:
add support for ext_vector_type and overloadable attributes