Re: More Objective C @"string" bugs...

[Nicola Pero <n dot pero at mi dot flashnet dot it>]

> It looks like no one updated the ObjC front end for this change:

I wonder if it was not the responsibility of the person who made the
change to update it.  Or - at least - he should have warned people working
on other front ends (other than C/C++) that they needed to update their
front ends, and how.

rest_of_decl_compilation is used in all front ends I have (C, C++,
Objective-C, fortran, java), and presumably in all front ends I don't have
as well.

I wonder what a nightmare it should be to write and maintain a gcc front
end for a language, if it would be broken that way, that hard, and that
silently - and that routinely.  A random anonymous entry in the ChangeLog
(one in thousands) - no notice on mailing lists - and zack! - a radical
change was made - your front end still compiles - but in reality it is
broken - subtle bugs are creeping in - now you can happily spend your next
two days/weeks/months figuring out that your front end is buggy - and
where - and why.

And I have some notice of this nightmare by looking at the fact that a
perfectly working front end (Objective-C) - kept on the gcc cvs
repository, with a stable maintainer and a big userbase - has been reduced
to a pathetic state by careless gcc hackers in less than one year.  Such a
pathetic state that nobody is using it (not even for testing), and
everyone is still using gcc-2.95 to compile Objective-C.

Are people writing frontends supposed to spend their days reading all the
commits to gcc, figure out what was changed in each of them, and update
all their code ?  That means you spend all of your time just to keep your
existing code to work.

Wouldn't it be simpler if the person who makes a change in the core of gcc
- which could break frontends - updates the frontends kept in the gcc
repository and informs external developers that they need to update
theirs, and how ?  I know this adds quite a overhead for the core gcc
hackers - all quality procedures adds a certain overhead - but what relief
for front ends.

As a newcomer to gcc development, the fact that an existing working
frontend (correct code!) is broken silently and randomly by gcc core
development commits seems to me a wicked combination of ugly program
design and - particularly in the case of frontends which are kept in the
gcc repository - very bad habits of some gcc hackers who don't take into
account the existence and importance of front ends different from C/C++.


> 2001-02-26  Jason Merrill  <jason@redhat.com>
> 
>         * c-decl.c (finish_decl): Set DECL_DEFER_OUTPUT on tentative file-scope
>         definitions.
>         * toplev.c (rest_of_decl_compilation): Check DECL_DEFER_OUTPUT to
>         recognize a tentative definition.  Lose obsolete code.
> 
>         * toplev.c (wrapup_global_declarations): Don't emit DECL_COMDAT
>         variables unless necessary, either.
> 
> objc-act.c is assuming it's safe to call rest_of_decl_compilation on a
> half-initialized decl and then set its constructor, which is no longer
> true.  The appended patch makes my test program compile and run
> successfully.  I've also changed the existing string[12].m so that
> they don't mask the bug anymore.