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.