Re: [pph] Make libcpp symbol validation a warning (issue5235061)

[Gabriel Charette <gcharette1 at gmail dot com>]

Yes, I understand that.

But when the second 2.pph is skipped when reading foo.pph, the reading
of its line_table is also skipped (as foo.pph doesn't contain the
line_table information for 2.h, 2.pph does and adds it when its
included as a child, but if it's skipped, the line_table info for 2.h
should never make it in the line_table), so I don't see why this is an
issue for the line_table (other than the assert about the number of
line table entries read). What I was suggesting is that as far as the
assert is concerned it would be stronger to count the number of
skipped child headers on read and assert num_read+num_skipped ==
num_expected_childs basically (it is still only an assert so no big
deal I guess).

Essentially this patch fixes the last bug we had in the line_table
merging (i.e. that guarded out headers in the non-pph version weren't
guarded out in the pph version) and this is a good thing. I'm just
being picky about weakening asserts!


I still think it would be nice to have a way to test constructs like
the line_table at the end of parsing (maybe a new flag, as I was
suggesting in my previous email, as gcc doesn't allow for modular
testing) and compare pph and non-pph versions. Testing at this level
would potentially be much better than trying to understand tricky test
failures from the ground up. This is beyond the scope of this patch of
course, but something to keep in mind I think.

Gab

On Fri, Oct 14, 2011 at 8:16 AM, Diego Novillo <dnovillo@google.com> wrote:
>
> On 11-10-13 17:55 , Gabriel Charette wrote:
>
>> I'm not sure exactly how you skip headers already parsed now (we
>> didn't used to when I wrote this code and that was the only problem
>> remaining in the line_table (i.e. duplicate entries for guarded
>> headers in the non-pph compile)), but couldn't you count the number of
>> skipped entries and assert (line_table->used - used_before) +
>> numSkipped == expected_in) ?
>
> The problem is that the compilation process of foo.h -> foo.pph may generate different line tables than a compile that includes foo.pph. For instance,
>
> foo.h:
> #include "1.pph"
> #include "2.pph"
> #include "3.pph"
>
> foo.cc:
> #include "2.pph"
> #include "foo.pph"
>
>
> When we compile foo.h, the line table incorporates the effects of including 2.pph, and that's what we save to foo.pph. ÂHowever, when compiling foo.cc, the first thing we do is include 2.pph, so when processing the include for foo.pph, we will completely skip over 2.pph.
>
> That's why we cannot really have the same line table that we had when we generated foo.pph.
>
>
> Diego.