Re: Save macro data structures in PCH file

[Zack Weinberg <zack at codesourcery dot com>]

gkeating@apple.com (Geoffrey Keating) writes:

> This patch rearranges the way that macro definitions are saved in PCH
> files.  Before the patch, the definitions were saved as textual
> strings, and macros defined on the command-line were saved as a copy
> of the internal data structures. 
[...]

I'm quite happy to see this patch, but I have some kibitzes
and a wishlist item.

1)  cpp-id-data.h should not be in libcpp/include; that data is _not_
    part of the public interface.  If that means code over in gcc/ has
    to jump through more hoops, so be it; code in gcc/ that gets its
    fingers into cpplib internals _should_ have to jump through hoops.
1a) For similar reasons, cpp_token_val_index ought to be a _cpp_
    interface name, and be prototyped in cpp-id-data.h not cpplib.h.

2) Do not create a separate changelog for libcpp/include.
3) stringpool_ggc_alloc is unnecessary.
4) Please document nested_ptr.
5) Can gt_pch_fixup_stringpool be deleted?
6) Any reason not to give the rest of the cpplib state the same treatment?

i) Could you please look into making gengtype/ggc/pch handle obstacks
   backed by ggc_alloc?  (that is, _obstack_begin called with
   ggc_alloc/ggc_free for its last two arguments)  Desired semantics
   would be to recognize an obstack page as live if any interior
   pointer existed, and serialize/deserialize safely to PCH.  Bonus
   points for deallocating obstack pages automatically when they come
   free, but the thing I want this for never deallocates, so it's not
   essential.

zw