On 3/12/07, Mike Stump <[EMAIL PROTECTED]> wrote:
On Mar 12, 2007, at 2:14 PM, Paolo Carlini wrote:
> When I said, let's support Doug, I meant let's support Doug from a
> *practical* point of view. Either we suggest something doable with
> a realistically sized effort or a little larger and at the same
> time we volunteer to actually do it. In my opinion, "visions" for a
> better future do not help here.
I'd disagree. It is nice to have a stated idea of where we want to
go, even if we can't get there today. We can measures patch goodness
by how closely each patch moves us in that direction. That said, we
all realize we are _not_ asking Doug to please re-implement the C++
frontend to our design to fix this issue. I'd be against that.
Making C++ use a few tree codes (a la the back end) and burying the
`extended' code in the C++ frontend sounds enticing, sounds like less
work than redoing the FE to not use trees entirely and a step in the
right direction. I checked the Objective-C frontend, it seems
possible to do it as well. The tree_contains_struct stuff seems the
`hardest' to get right, though, for Objective-C I think we could get
by with 2 tree codes, maybe. Those that have TS_DECL_NON_COMMON,
TS_DECL_WITH_VIS, TS_DECL_WRTL, TS_DECL_MINIMAL and TS_DECL_COMMON
and those without?
Feel free to make TS_ structs that do what you need, and use them.
They correspond to the structs that are contained into each decl node in tree.h
How the decl hiearchy is organized is explained in the docs, as well
as how to add a new "subclass".
For non-DECL nodes (or anything else), you'd want to make up your own TS_ stuff.
(tree_contains_struct not only made the checking easy, it bought us
some bits that were stored on every DECL tree, like whether it could
contain RTL or not)
