r187174 - Fix GNU ObjC ABI for a message returning a struct.

[John McCall]

On Jul 26, 2013, at 5:05 PM, Jonathan Schleifer <js at webkeks.org> wrote:
> Am 27.07.2013 um 01:54 schrieb John McCall:
>> The feature enables users to rely on arbitrary message forwarding if they're willing to live on certain minimum compiler and runtime versions.  That’s a pretty simple and comprehensible message for users.
>> 
>> In fact, if I remember correctly, we didn’t actually support generating code correctly for your runtime until fairly recently, so your users are all perfectly aware of the concept of a minimum compiler version.
> 
> You are oversimplifying things here. There was no support for the ObjFW runtime before 3.2, but that didn't mean that Clang 3.1 could not work with it: It could, and it worked well, it was just that certain features were unavailable.
> 
> This, however, is different. It will mean that using an old Clang version or GCC will generate *crashing code* instead of a feature being unavailable. That's a completely different thing!

It’s going to generate crashing code anyway.  You can’t statically detect that the user’s using this feature — you’d, what, add code to the compiler that detects that the user has defined forwardingTargetForSelector: in a way that might accept a selector that you think probably has an indirect return?  So in practice the process from the user’s perspective is:

1. The user writes some code that relies on proxying.
2. It compiles without complaint.
3. It crashes because they’re using an old compiler or runtime (but not immediately — only when the first indirect-return message is forwarded).
4. The crash is exactly the same regardless of the runtime version, because the old compiler is calling objc_msg_lookup, and as long as proxying is enabled *at all* for this target, objc_msg_lookup will return back the non-indirect forwarding function and the current behavior will recur.
5. The user figures out, somehow, that it’s because of this bug with proxying methods with indirect returns.
6. The user finds your documentation about this, which says that they need a new compiler version.
7. Profit?

The only way that this preprocessing check is useful at all is if the user’s reaction to this is “Oh, I can't upgrade my compiler; I’ll just add workarounds every time I run into this crash, but I want to disable them when the runtime feature is enabled.”  And that might be a rational reaction, but it’s a rational reaction to *any possible compiler bug*.

I think that exposing the value of -fobjc-runtime as preprocessor state is a pretty reasonable request, although I don’t see how it solves this problem at all.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130727/4a4bf3dc/attachment.html>