This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

> As you can see, i have no large plans past moving out fields that are
> easy to move out. If someone wants to do massive restructuring (and
> changing all kinds of front end code, etc), that's fine, but i'd rather
> have something than nothing, and with the scheme i've described, the
> easy stuff is easy to move, and we still can keep dynamic typechecking.

I added how i plan to have language specific inheritance.
I don't believe that we can do better very easily, and I don't believe
including structures but not macros to access them in union tree_node is
a horrible thing compared to tree field (ab/re)use.

I've at least made sure that the languages are only determined at
configure time, instead of at tarball/whatever time.

It also doesn't matter what languages you select or what order they get
included in (unless the plan is to have objective C++ inherit structures
directly from the C++ FE, in which case you'd have to implement ordering
of some sort)

My current plans are to eliminate lang_specific and the lang flags
absolutely last, since it is the hardest, and probably most
controversial part of all of this.

I'm also not tied to the exact mechanism i've shown for union tree_node.
The major point is that in some fashion, all the structures we are going
to have from all the frontends get put into the same union, and have

This is of course, the plan i am willing to commit to working on.   I'm
happy to consider working on alternate schemes, as long as they aren't
going to take 3 person-years of time for me to implement (because i
believe we need something much sooner than that), or consist of "make
the compiler add meta-data" :).

I think at the start, we should be shooting for something simple,
achievable, and does not prejudice future goals others may have. 
For example, I don't believe removing the structures being globally
visible in the union or not having a union favor of some casting is a
significantly hard goal once the structures exist.  I believe making the
language specific structures and inheritance exist in some form, work
right, and be usable is more important than whether it is absolutely
perfectly and the absolute best we can do.
After all, what we have now is nothing but tree field (ab/re)use.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]