Re: [objc-improvements] Merging back to mainline

[David Ayers]

Ziemowit Laski wrote:

> The question that I have is therefore the following: Does the
> objc-improvements-branch, in its present shape, fail to build GNUStep
> or any associated apps or, if they do build, has their behavior
> changed in some erroneous way? If the answer is yes, then we
> should definitely fix any remaining bugs before moving forward.
> But if the answer is no, I think we should go for the mainline merge.
> We really can't put this off any longer if we hope to get this stuff
> into the 3.4 release. Once the objc-improvements-branch fixes have
> made it into the mainline, we can continue addressing the remaining
> issues.

Technically, we still have strong concerns about the changed code 
generation due to the new assumptions the compiler makes in cases of 
conflicting prototypes. These should definitely should be resolved 
before any merge takes place.

For those not following the discussion on gnustep-discuss, the branch 
currently assumes IMP '(id)(*)(id)(SEL)...' for id/class typed receivers 
that have conflicting prototypes. The problem is that the return type 
could have been consistently different than id (and of a different size) 
with only minor conflicts in the exact class/subclass of a parameter. 
The old assumption would generate correct code, if these conflicts were 
minor. The IMP assumption could either break code generation or cause an 
outright compile error. Also float arguments, which often get used in 
OPENSTEP-like implementations, would get promoted to doubles through 
varadic processing. We have been discussing alternative approaches.

On the other hand we are missing a comprehensive summary of the actual 
additional features contained in this branch, and how they relate to the 
GNU runtime. Those of us, who have been working with you, have got 
involved more deeply through the circumstance that the branch simply 
didn't generate correct code for us. Through that we got /some/ idea of 
/some/ of the features but those have generated ... let's say mixed 
responses.

I understand that you have limited time and 3.4 is getting tight, but I 
think it's not too much to ask for a discussion of these features and 
especially how they relate to the GNU runtime. We were hoping to not 
have to burden gcc-patches or gcc lists with that discussion, and we're 
thankful for your efforts to potentially host an ObjC mailing list for 
the future (eventhough I personally would have prefered a FSF gcc hosted 
list, but hey, for this time around lets be as pragmatic as we can.)

But the first step would be to present the 'improvements', so may I 
throw the ball back in your corner :-). Personally, I'll try to be as 
cooperative and responsive as I can to get a consensus on how to merge 
these features in a meaningful way.

Cheers,
David Ayers