recent regression

Sat Jun 26 09:57:00 GMT 2004

Ranjit Mathew wrote:
>This is because read_class() isn't quite equipped to handle source
>files that have been parsed already and it unnecessarily calls
>find_class() that emits this warning all over again.
>>I had submitted this patch to resolve this issue a few days
>back:
>> http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01589.html
>>(For some reason this mail didn't get archived in the java-patches
>archives.)
>>
Weird. I never received it in java-patches either.
>Note that some time after the original code for parsing/laying-out
>was written, the meaning of CLASS_LOADED_P was changed:
>> http://gcc.gnu.org/ml/java/2001-04/msg00114.html
>>and CLASS_PARSED_P was introduced. This meant that if you
>read code like the following (that's quite common throughout
>the front end):
>> if (! CLASS_LOADED_P (cls))
> load_class (cls);
>>and naively assumed that after this CLASS_LOADED_P (cls) would
>be true, you'd be wrong. :-/
>>
Yeah. Code along the lines of the following, which ought to guarantee 
that CLASS_LOADED_P gets set, is reasonably common:
 if (! CLASS_LOADED_P (class_decl))
 {
 if (CLASS_FROM_SOURCE_P (class_decl))
 safe_layout_class (class_decl);
 else
 load_class (class_decl, 1);
 }
I wonder if this functionality should just be encapsulated into 
load_class, or some other new function - it would simplify code at the 
call sites and also guarantee that CLASS_LOADED_P is true upon 
returning. Do we ever really want to load a class and not lay it out?
Regards
Bryce