Re: Patch: PR java/20031 - ICE on missing files

[Andrew Haley <aph at redhat dot com>]

Ranjit Mathew writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > Andrew Haley wrote:
 > > Ranjit Mathew writes:
 > [...]
 > >  > 
 > >  > The contentious bit would probably be my proposal to use
 > >  > TYPE_DUMMY on a RECORD_TYPE node to indicate a failed
 > >  > loading of the class, even in the non-indirect-dispatch
 > >  > case when VERBOSE is true and to use this to not bother
 > >  > to lay out a class's methods if it failed loading.
 > >  > 
 > >  > As I understand it, VERBOSE is set to 1 for load_class()
 > >  > when we expect the class to be found and consider it an
 > >  > error if it is not. In this case, if the class failed
 > >  > loading, there does not seem to be any hope of finding it
 > >  > later and therefore it is better to "poison" the RECORD_TYPE
 > >  > denoting the class. I would like to know if this assumption
 > >  > is invalid.
 > [...]
 > >  > 
 > >  > OK for mainline?
 > > 
 > > I can't say it fills me with happiness.  Is there really no better way
 > > to do this than to (ab)use TYPE_DUMMY ?  OK, if you really want to do
 > > this go ahead, but at least add some commentary to the effect that
 > > when compiling without indirect dispatch this really is a fatal error,
 > > but we're continuing in case we need to generate further disgnostics.
 > 
 > I don't wish to push this patch through unnecessarily.

Yeah, and I'm aware that a mainatiner's job is to ease development,
not to impose his personal tastes on everyone.  :-)  I'm trying for
some sort of happy medium...

 > A much simpler fix would be to turn that error() into a
 > fatal_error(), but then we lose out on further diagnostics as you
 > point out. A better fix would perhaps be to make load_class()
 > return a status code (success/error) that the caller can check to
 > see if it makes sense to proceed with the class or not.
 > 
 > The problem with just a return code is that if we retain that
 > RECORD_TYPE node and use it elsewhere in the compiler, those parts
 > also need to know that it is merely a placeholder and the
 > respective class was not found. We need some way of percolating
 > this information and hence my (ab)use of TYPE_DUMMY.
 > 
 > By the way, there are several:
 > 
 >   if (!CLASS_LOADED_P (foo))
 >     load_class (foo, 1);
 > 
 > fragments throughout the front-end that should be updated to check
 > the status of that load_class().

I was thinking of something like checking that the class was valid in
some way without using TYPE_DUMMY, which hitherto has had a very
specific meaning.

Andrew.