[Bug preprocessor/70518] Conditional compilation of #line directives

["manu at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70518

Manuel LÃpez-IbÃÃez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #2 from Manuel LÃpez-IbÃÃez <manu at gcc dot gnu.org> ---
(In reply to Kyle Guinn from comment #0)
> Should #line be processed unconditionally?  I know the preprocessor has to
> keep track of nested #if blocks so that it can find the matching #endif when
> the block is disabled.  This seems like a corner case that I don't know if
> the C standard ever considers.  If so, it may simplify the next part.

I would be surprised if GCC and Clang are not following the standard here,
since #line also determines __FILE__ and __LINE__.

> The bug:  Misleading error messages.  It opens template.c and prints line 8
> from it (assuming this file exists and has at least 8 lines).  It's not the
> offending line; it could be any text:

Well, it is the line that the file tells gcc to look up. A work-around would be
to reset #line to the proper place after the #endif.

> Also note the "In function âmainâ" message is using template.c instead of
> the actual file that main appears in (main.c) and that __FILE__ is set to at
> the start of its definition.

Indeed that looks wrong to me. Perhaps worth opening a different PR to track
that issue.

> Somehow clang prints out the right offending statement but keeps the
> "template.c:8" text:

Probably it keeps track of both the "preprocessor" location and the actual
source location. Not sure how it does that efficiently or if there is some
other heuristic involved. GCC is quite far away from being able to do that.