[RFC] Thoughts on reordering the source tree

[Joseph S. Myers]

On Fri, 1 May 2009, Steven Bosscher wrote:

> > And these are the problem inclusions of files specific to C and ObjC from
> > files also shared with C++:
> >
> > c-common.c:#include "c-tree.h"
> > c-dump.c:#include "c-tree.h"
> > c-gimplify.c:#include "c-tree.h"
> > c-lex.c:#include "c-tree.h"
> > c-opts.c:#include "c-tree.h"            /* For c_cpp_error.  */
> > c-pretty-print.c:#include "c-tree.h"
> 
> Can you explain a bit more about this is problem?  Do you already have
> some idea what needs to be done?
> 
> As an example, I was looking at c_build_qualified_type().  It is
> prototyped in c-tree.h, defined in c-typeck.c, and used in c-common.c.
>  How should such cases be fixed?

Once we had a bug along the following lines: a function (maybe comptypes, 
though c-common.c doesn't call that function right now) was defined with 
different prototypes for C and C++, and c-common.c included c-tree.h, got 
the appropriate prototype for C, passed appropriate arguments for C to 
that function, and passed random data as the extra argument C++ had when 
used from the C++ front end.

For each function called by c-common.c that's not defined in common code, 
there is in fact an interface to that function shared by C and C++; if the 
interface is different, we have a bug like the above.  So these common 
interfaces should be declared in c-common.h, and not in headers specific 
to C and C++.  If files shared by C and C++ do not include headers 
specific to just one language, bugs such as the above are much less likely 
to occur.

In this case, c_build_qualified_type is already prototyped in c-common.h 
(c-tree.h has a use of it, not a prototype), so nothing needs to change.  
But if c-common.c uses a prototype from c-tree.h, move that prototype to 
c-common.h, and remove any copy of it in any C++ front-end header.

-- 
Joseph S. Myers
joseph@codesourcery.com