Re: PATCH: ObjC-specific changes to c-typeck.c

[Ziemowit Laski <zlaski at apple dot com>]

Let me address Zack's question first.

The patch is not entirely equivalent to the code it replaces.  Before 
my patch,
even though TYPE_MAIN_VARIANT is not traversed for ObjC types, the code 
still
falls through to further checks, warnings, convert() calls, etc.  This 
is not
desired ObjC behavior.

As for Joseph's question, I don't know if I presently have a test 
failure that
I could point to as being fixed by this patch, though I do recall seeing
failures stemming from it in the past (e.g., I could have sworn that 
gcc.c-torture/compile/20010605-2.c
used to be one such failure; ongoing development may have masked or 
worked around the
problem.)  The reason I'm including the patch here is because it is the 
correct
thing to do for ObjC.  Not including such a patch would require me to 
prove that
the remainder of build_c_cast() produces the equivalent of 'return 
build1 (NOP_EXPR, type, expr)'
for all execution paths.  Even if provable, such an assertion would be 
subject to change
without notice as other people muck in build_c_cast() (or its children) 
in the future. :-)

Further, since Joseph asserts that this is an ObjC-specific patch, I 
feel morally empowered to
commit it, barring any regressions or other undesirable non-ObjC 
effects.  Are there any?

--Zem


On 24 Aug 2004, at 1.41, Joseph S. Myers wrote:

> Actually, I declined to review it because I didn't consider 
> ObjC-specific
> code within my competence (and I consider what part of the compiler 
> code
> is associated with to be more a matter of function than of what source
> file it is located in).
>
> Past release criteria have said that the behaviro of the ObjC and Ada
> front ends "will not be a primary consideration in determining whether 
> or
> not to ship a particular release candidate" so there may be a *little*
> more latitude allowed to changes to those parts of the compiler than to
> changes elsewhere, but as regressions still need to be avoided and the
> code still needs to be maintainable by people who may not be familiar 
> with
> it, you should still seek to satisfy people with concerns that those
> concerns are addressed, and add comments to the code explaining 
> anything
> about it and why it is needed that has proved unclear.
>
> Is this change needed for some particular testcase already in the
> testsuite (failing or XFAILed), already in the testsuite (which however
> only fails when other changes are merged in, in which case you may 
> need to
> explain why the problem is here rather than with the other changes), 
> or is
> the testcase something not currently in the testsuite?  Please name the
> test or provide the testcase which fails before the patch and passes
> afterwards, or the explanation for why there can't be a testcase.  All
> patch submissions should include testcases, references to existing ones
> that are fixed or explanations of why one can't be included or isn't
> needed, unless immediately obvious.
>
> --
> Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
>     jsm@polyomino.org.uk (personal mail)
>     jsm28@gcc.gnu.org (Bugzilla assignments and CCs)
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477