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

[Mark Mitchell]

Daniel Berlin wrote:
>>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.

I really didn't mean it as any kind of personal comment.  What I'm 
worried about is not your follow-through, but the fact that it's a big 
project and you may get blocked or have to stop for lots or reasons.  In 
that case, I want to make sure that we have something we can look back 
at later and say "yes, OK, here's what we were trying to do" rather than 
just guessing.

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

CodeSourcery did submit a proposal to an interested customer regarding 
this kind of work recently.  Frankly, it's work that Nathan is very 
eager to do.  Of course, whether or not we get the job will have a big 
impact on how much time we can spend.

>>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.

For example, how are you going to make macros that should work at 
multiple levels of the hierarchy (like DECL_CONTEXT) work right?  Are 
front ends allowed to inherit without changing the base tree code? 
Things like "how to add a new tree to the hierarchy" would be nice.

> 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.

Good; that's all I'm asking!

>>>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.

Well, to be accurate, I believe that we'll end up with various common 
pieces, derived from the base-of-all-bases, used by multiple "final" 
classes (in Java parlance).  I'd expect, for example, that we have a 
tree_var_or_function_base -- from which NAMESPACE_DECL and CONST_DECL 
probably do not derive.

>>>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.

I wasn't aware of that, and am not necessarily keen on it either, but I 
agree that you're not breaking new ground in the way that I was afraid, 
and therefore withdraw my objection.

>>It doesn't make sense to have DECL_FIELD_CONTEXT.
>  
> DECL_FIELD_CONTEXT already exists, maybe you think i added it?

I did think that -- because we've pretty much never used it!  My 
mistake.  In fact, though, I think it should just be removed -- it 
serves no useful purpose.  You could do that as a separate pre-patch, or 
just ignore it; I agree it's not your problem.

> 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.

I think that makes more sense -- but this is exactly the kind of thing 
that I'd rather see addressed in a design document so other people can 
express their opinions too.  There will likely be some case-by-case 
stuff here, but getting a consensus on the right defaults would be helpful.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304