Re: [PATCH] Move class substring_loc from c-family into gcc

[Martin Sebor <msebor at gmail dot com>]

On 09/03/2016 03:13 AM, Manuel López-Ibáñez wrote:
> On 02/09/16 23:55, Martin Sebor wrote:
> > > diff --git a/gcc/substring-locations.h b/gcc/substring-locations.h
> > > index f839c74..bb0de4f 100644
> > > --- a/gcc/substring-locations.h
> > > +++ b/gcc/substring-locations.h
> > > @@ -20,6 +20,73 @@ along with GCC; see the file COPYING3.  If not see
> > >   #ifndef GCC_SUBSTRING_LOCATIONS_H
> > >   #define GCC_SUBSTRING_LOCATIONS_H
> > >
> > > +#include <cpplib.h>
> > > +
>
> Is this header file going to be used in the middle-end? If so, then it
> is suspicious that it includes cpplib.h. Otherwise, perhaps it should
> live in c-family/

I'm not sure if you meant this question for me or for David but
I believe the main (only?) reason for this patch is let to make
use, in the -Wformat-length middle-end pass, of the same range
location API as in c-family/c-format in the C/C++ front ends.
David, please correct me if I mischaracterized it.

Martin

> I'm not complaining about substring-locations.c because libcpp is
> already linked with everything else even for other non-C languages, like
> Ada, but the above is leaking all cpplib.h into the rest of the
> compiler, which defeats the purpose of this in coretypes.h
>
> /* Provide forward struct declaration so that we don't have to include
>     all of cpplib.h whenever a random prototype includes a pointer.
>     Note that the cpp_reader and cpp_token typedefs remain part of
>     cpplib.h.  */
>
> struct cpp_reader;
> struct cpp_token;
>
>
> Cheers,
>      Manuel.