public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Gabriel Charette <gcharette1@gmail.com>
To: Diego Novillo <dnovillo@google.com>
Cc: reply@codereview.appspotmail.com, crowl@google.com,
		gcc-patches@gcc.gnu.org
Subject: Re: [pph] Make libcpp symbol validation a warning (issue5235061)
Date: Sat, 15 Oct 2011 08:00:00 -0000	[thread overview]
Message-ID: <CAAb05gEV2Z_uxJJUCW3qpF4rTYNmZcGCszcKOEcDieYZz45pfQ@mail.gmail.com> (raw)
In-Reply-To: <4E982809.1010302@google.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.

  reply	other threads:[~2011-10-15  0:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-11 21:30 Diego Novillo
2011-10-13 22:39 ` Gabriel Charette
2011-10-14 13:43   ` Diego Novillo
2011-10-15  8:00     ` Gabriel Charette [this message]
2011-10-17 13:39       ` Diego Novillo
2011-10-21  5:53 ` Gabriel Charette
2011-10-21 19:06   ` Lawrence Crowl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAb05gEV2Z_uxJJUCW3qpF4rTYNmZcGCszcKOEcDieYZz45pfQ@mail.gmail.com \
    --to=gcharette1@gmail.com \
    --cc=crowl@google.com \
    --cc=dnovillo@google.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=reply@codereview.appspotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).