Re: Line 0 Hack??

[Gabriel Charette <gchare@google.com>]

I have removed the hack and the test output is identical to the clean
build test output.

See issue4835047 for the patch.

Gabriel

On Mon, Aug 1, 2011 at 2:56 PM, Gabriel Charette <gchare@google.com> wrote:
> Re-sending as plain text for gcc@gcc.gnu.org ...
>
> ----------------------------
>
> Hi,
>
> I have a question about the line 0 hack on line 13232 of gcc/cp/decl.c
> (or just text search for "Hack", it's the only place it's found in
> that file...).
>
> From my revision history, Steven introduced this in 2005, and Tom
> modified it in 2007 (probably when modifying the linemap).
>
> The problem is that this very call to get the source_location of line
> 0 creates a NEW linemap entry in the line table, AFTER all of the
> LC_LEAVE have taken place (i.e. we were done parsing and now add a new
> linemap to the line_table)...
>
> And hence, we finish the parsing with line_table->depth == 1.
>
> In particular, I am building linemap serialization for pre-parsed
> headers, and added what I think to be a fair gcc_assert that when we
> serialize the line_table, it's depth should be 0. However, if we
> happen to have "main" in the header (this is when we get in this block
> in decl.c from my understanding as DECL_MAIN_P is then true), a new
> linemap is added at the end of the line table in the header after the
> LC_LEAVE... when merging this in the middle of a C file upon
> deserializing, this entry makes no sense, but I can't just ignore it
> either as a source_location has been handed off for it...
>
> My question is, what is this "special line 0" is this just a hack for
> this particular situation or is "line 0" a much more important concept
> I can't mess around with?
>
> I could potentially hack around it, but hacking around a hack can only
> make things worst in the long run..
>
> I'm not familiar with the "middle end warning" referred to in the
> comment in decl.c, could we potentially once and for all get rid of
> this hack?
>
> Best,
> Gabriel
>