Re: [PATCH]: Move FIELD_DECL into it's own structure

[Daniel Berlin <dberlin at dberlin dot org>]

> I like the idea of this patch, but I'm concerned about a few issues.
> 
> One is that if we go a little way down this path, but not all the way, 
> we could end up truly tangled.  I don't know exactly what to do about 
> that, except ask you to promise to keep going for a while.  In other 
> words, I'm a little nervous about this being a weekend project that then 
> gets dropped after a weekend or two with no clear plan.

If you don't believe i will finish what i start, or leave things in a
bad state, you are more than free to not accept the patch.  I'm really
not going to play this game.

>   In fact, it 
> would be nice if there were a Wiki page with objectives and methodology 
> explaining what you're trying to do so that other people could help. 

I'm happy to, but i doubt anyone wants to help. After all, nobody has
done this stuff in years!

> I'd include things like how you plan to emulate inheritance in C, and 
> how the macros and such will have to work for that. 

The same way we do now. I'm not sure what you expect me to say.
Things that are shared have some common base class, and are all in the
union together so that they overlap approriately.

There will never be multiple inheritance, so such a scheme should work
fine.

>  In the end, this is 
> documentation that we'll want anyhow for future development.
> 
> I'm not trying to throw up roadblocks, nor asking you to write a book. 
> But, this is a major change to the way GCC's IR works, and nobody is 
> happy with the current lack of design and documentation. 
>  I think you 
> need to lay the appropriate foundation, and get buy-in, before we start 
> hacking.

I'm happy to write the methodology and design docs for the structure of
the trees.
I have no plans to attempt to revise the documentation of the existing
macros, or try to describe how the frontends are using these things.


> > All things not in common with FIELD_DECL and all other DECL's was moved
> > to tree_decl_extra. This is just a temporary storage place as
> > structures get moved around and split. 
> 
> In the way of temporary changes, this will likely live forever. 
If you believe so, that's fine.

>  And, as 
> you say, you want to split things out of CONST_DECL, etc., later, 
> leading to additional shared structure types.  So, tree_decl_extra isn't 
> a good name.  For now, tree_non_field_decl_common is probably the best 
> we can do.

Changed.

> 
> > A tree_class_except macro was added to be able to check that something
> > is any member of a tree class *except* some member.  This is used to
> > make sure nothing is still trying to access the moved fields in a
> > FIELD_DECL.
> 
> I'm not sure this is a very good idea.  You've made the logic rather 
> more complex by adding negation. 

This is what we do in other places (see TREE_NOT_CHECK*), so i'm not
sure what you think i'm doing wrong.

>  And, a front-end that inherits from 
> FIELD_DECL would now not work.

None of them do, and i don't see anyone rushing to change this. What is
stopping us from simply updating macros then?  This doesn't seem to me
to be a good reason.

In any case, the checks were mainly there for debugging, so that every
case was caught.  I have no problem with assuming people know what
fields can be set on fields, and what can't, which is what used to
happen (IE it wouldn't fail, it would just do weird things).

>   I'd rather we stay with positive-only 
> checks.

Uh, again, you realize we have a *large* number of non-positive checks
in there already, right?

If you inherited from VAR_DECL or PARM_DECL, you'd get bitten
immediately.

In fact, none of the non-specific positive checks for DECL_ are really
positive checks, they just check that the tree is of class
tcc_declaration.

What exactly do you want me to do here?  Change all the DECL_CHECK's to
be specific to the trees that use them.
If so, i'm only willing to do that on a week by week basis.  I'm not
going to hunt down every use of every flag all at the same time and see
what tree codes are necessary for them, and change the checks.

> 
> It doesn't make sense to have DECL_FIELD_CONTEXT.

DECL_FIELD_CONTEXT already exists, maybe you think i added it?

As for the other TREE_CODE (decl) != FIELD_DECL checks, i'm happy to fix
the appropriate macros to just return NULL or false in those cases, if
you want.