Re: C Parser Cleanup

[Gabriel Dos Reis <Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr>]

Neil Booth <neil@daikokuya.demon.co.uk> writes:

| Seriously, I think you bring up an important issue.  I would hope that
| code in cp/ and objc/ only uses c-common.c (including c-format.c now
| that Joseph broke it off) and the tree* files.

Actually, from cp/Make-lang.in we have:

   cc1plus$(exeext): $(CXX_OBJS) $(CXX_C_OBJS) $(BACKEND) \
		     libcpp.a $(LIBDEPS)

and

   CXX_C_OBJS = c-common.o c-format.o c-pragma.o c-semantics.o c-lex.o c-dump.o $(CXX_TARGET_OBJS)


| ... Otherwise things get
| really confusing; the precise intended semantics of the various tree
| types and codes are pretty unclear as it is.

Yeah, the current state of affairs is really confusing when it comes
to add or factor functionality :-(

| I think there's a good argument for creating a c/ directory, and
| moving C (and C intersect ObjC) stuff into there to impove clarity in
| these areas.  I don't know what others think of this?

I think it is really a good idea to segragate the C front-end specific
bits a dedicated directory, pretty much in the same that is done for
other front-ends.

| It would also help in the move towards "tree" being a more concrete
| abstraction, if that's not an oxymoron.  My understanding is that this
| is the way we want to go, away from some of the incestuousness "tree"
| has with various front ends.  For example, the tree documentation for
| the "standard" types should be able avoid references to any front end,
| except for illustrative examples.  A glance at existing documentation
| shows this is far from true at present.

100% agreed.  Certainly c-tree.texi needs improvement.  For the
moment, I don't know where to put bits concerning C++ template
representation.  Historically c-tree.texi had been cp/tree.texi; now I
don't know where to put C++ specific bits.

| Making "tree" more object oriented, possibly through a per-type
| op-table of function pointers like Mark mentioned a few days ago,
| sounds like a good long term goal to me.

That will certainly bring in modular continuity and enhance
encapsulation, which are definitely big wins.

However, I don't how "long term" that long term project is.

-- Gaby