Fix for ObjC Class / id definition regression

Hi,

The attached diff fixes the recently-introduced regression where clang ignores the definitions of the Objective-C types in a header (although not, I believe, from a precompiled header, although I'd need to check that). The attached test.m is a preprocessed file including one of the GNU runtime headers which demonstrates the problem. This will also be a problem with the legacy Apple runtime, but not with the modern runtime (where these types are opaque).

David

clang.diff (827 Bytes)

test.m (1.87 KB)

Please ignore this patch, it breaks more than it fixes (although the problem is real and does prevent clang from working with any Objective-C programs on non-Apple platforms and possibly on Apple platforms with the legacy runtime).

David

Hi all,

To compile the ARM target in the revision 78471 (with cmake + VS), the file “llvm\lib\Target\ARM\CMakeLists.txt” (revision 78471) needs a reference to the Thumb2SizeReduction.cpp source file.

Regards,
Makslane

Fixed.

Having looked at this in more detail, I am finding it increasingly difficult to see what the correct fix is.

The current code, which simply ignores the definition for any type named id or Class, is obviously wrong (and breaks lots of existing code, for example anything that includes the standard GNU runtime headers).

A fix needs to allow fields on variables of type id and Class to be accessed with normal C semantics, but also allow the pointers with the id and Class types to be receivers for messages. Every approach I've tried breaks at least one of the required semantics.

David

Hi David,

The current code, which simply ignores the definition for any type
named id or Class, is obviously wrong (and breaks lots of existing
code, for example anything that includes the standard GNU runtime
headers).

Probably makes sense to file a PR with a preprocessed input attached
to it for Steve to look at.

A fix needs to allow fields on variables of type id and Class to be
accessed with normal C semantics, but also allow the pointers with the
id and Class types to be receivers for messages.

Which pointers within the types are used? We support isa via the
custom ObjCIsaExpr, but are there other fields which are used in
common code?

- Daniel

Hi David,

The current code, which simply ignores the definition for any type
named id or Class, is obviously wrong (and breaks lots of existing
code, for example anything that includes the standard GNU runtime
headers).

Probably makes sense to file a PR with a preprocessed input attached
to it for Steve to look at.

Done: http://llvm.org/bugs/show_bug.cgi?id=4701

A fix needs to allow fields on variables of type id and Class to be
accessed with normal C semantics, but also allow the pointers with the
id and Class types to be receivers for messages.

Which pointers within the types are used? We support isa via the
custom ObjCIsaExpr, but are there other fields which are used in
common code?

isa, unfortunately, is no use. On the GNU runtime, id contains one field which is called class_pointer. While this is irritating, there is a lot of legacy code that depends on it.

Class (struct objc_class*) contains a number of fields which code accesses directly. With the legacy Apple runtime these are deprecated but still accessible. With GNU runtime they are all public. To make matters worse, the GNU objc-api.h includes some inline functions for setting and getting these fields which means any code that includes this file (i.e. all Objective-C code.h) will fail to compile with clang.

David

Hi David,

I just returned from vacation (sorry for the delayed response).

I'm not surprised there is some "fallout" from the id/Class change.

I'll contact you directly to see if you need any help resolving this.

Thanks,

snaroff