On 26/07/16 18:11, David Malcolm wrote:
gcc/ChangeLog:
* gcc.c (cpp_options): Rename string to...
(cpp_options_): ...this, to avoid clashing with struct in
cpplib.h.
It seems to me that you need this because now gcc.c includes cpplib.h via
input.h, which seems wrong.
input.h was FE-independent (it depends on line-map.h but it is an accident of
history that line-map.h is in libcpp since it doesn't depend on anything from
libcpp [*]). Note that input.h is included in coretypes.h, so this means that
now cpplib.h is included almost everywhere! [**]
There is the following 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;
precisely to avoid including cpplib.h.
If I understand correctly, cpplib.h is needed in input.h because of this
declaration:
+extern const char *get_source_range_for_substring (cpp_reader *pfile,
+ string_concat_db *concats,
+ location_t strloc,
+ enum cpp_ttype type,
+ int start_idx, int end_idx,
+ source_range *out_range);
Does this really need to be in input.h ? It seems something that only C-family
languages will be able to use. Note that you need a reader to use this
function, and for that, you need to already include cpplib.h.
Perhaps it could live for now in c-format.c, since it is the only place using
it?
Cheers,
Manuel.
[*] In an ideal world, we would have a language-agnostic diagnostics library
that would include line-map and that would be used by libcpp and the rest of
GCC, so that we can remove all the error-routines in libcpp and the awkward
glue code that ties it into diagnostics.c.
[**] And it seems that we are slowly undoing all the work that was done by
Andrew MacLeod to clean up the .h web and remove dependencies
(https://gcc.gnu.org/wiki/rearch).
