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
