Re: Save macro data structures in PCH file

[Zack Weinberg <zack at codesourcery dot com>]

Geoffrey Keating <geoffk@apple.com> writes:

> On 10/06/2004, at 12:52 PM, Zack Weinberg wrote:
>> 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.
>
> I considered this carefully while writing the patch.  I decided that
> this data, in the limited way in which it is used (that is, gengtype
> reads it), *should* be part of the public interface, and therefore
> should be in libcpp/include.  I would like to see gcc/ use only cpplib
> interfaces which are public.  There's no point saying "this interface
> isn't public, but you're allowed to use it anyway".

Point.  Okay, I withdraw this objection.

>> 2) Do not create a separate changelog for libcpp/include.
>
> It existed before I got there.  I'd be happy to see it merged with
> libcpp/ChangeLog.

Hmph.  I don't know where it came from.  I'll get rid of it.

>> 3) stringpool_ggc_alloc is unnecessary.
>
> ggc_alloc is a macro, and so you can't take its address.

Oops.

>> 4) Please document nested_ptr.
>
> Look in gty.texi:

Huh, how long has that been there, if you're just implementing it now?

>> 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.
>
> This is possible.  If you're interested in working on it, we should
> probably get together (preferably over beer, I will need it and so
> will you once you realise what is involved).

Okay.  Lemme see if the project I'm working on is actually worth it,
first.

zw