Re: [RFC] Fix bug report 11479

[Joel Brobecker <brobecker@adacore.com>]

> > I think that the proper solution would be to enhance function
> > cleanup_undefined_types_1 to also look at symbols inside function
> > symbols.  That way, the problem should be fixed for all kinds of
> > types, not just structs...
> 
>  I do not think that this is enough: the problem is more that
>  TYPE_STUB macro refers to the flag_stub of main_type, which means
>  that once the main_type flag_stub has been cleared, all types having
>  the same main_type will also return zero for TYPE_STUB.

It's definitely something i got myself confused over. In the stabs I posted:

        .stabs  "t:p(0,21)=*(0,22)=k(0,23)=xsdummy:",160,0,28,-24
        .stabs "dummy:T(0,23)=s16x:(0,1),0,32;y:(0,1),32,32;b:(0,13),64,64;;",128,0,0,0

Type dummy is numbered (0,23), whereas I talked myself into thinking
that type (0,23) would the be constant version of type dummy.  With
that confusion cleared, we do indeed clear the stub condition on our
type at the time when we read the second stabs line above. So, by the
time we reach the cleanup_undefined_types_1 stage, the type is actually
no longer undefined.

>   I still think that we should cycle over the type_chain when the type
>   is parsed.

I am afraid this might be the only solution indeed. For some reason,
even after our pretty comprehensive investigating, I am still pretty
reluctant about it, and I think it is because it looks wrong to
perform this relatively unintuitive operation, and just do it for
structs. Conceivably, you'd need to do the same for enums as well,
right?

I think we can reduce my anxiety by:
  - Adding detailed comments explaining what and why;
  - Putting the code inside a function so that we can reuse it elsewhere
    should the need arise;

Do you think that this would be an acceptable approach?

Sorry if I am slow, but stabsread, and stabs in general, are two horrible
deprecated pieces of technology - so it's hard to remain current.

-- 
Joel