https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90034
Akim Demaille <akim.demaille at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |akim.demaille at gmail dot com
--- Comment #8 from Akim Demaille <akim.demaille at gmail dot com> ---
(In reply to Richard Biener from comment #2)
> That said, bison should be fixed to not emit this kind of line directives...
Hi Richard,
I maintain Bison.
Bison is emitting two types of #lines: right before emitting code coming
from the input file, something like (1)
#line "parse.y" 42
and once we are done with the input, and back to generated code, something
like (2)
#line "parse.tab.c" 1024
What is special here is the way Bison and GCC were invoked:
bison -o /dev/stdout parser.y | gcc -xc -
So "of course", because the output file is /dev/stdout, we emit
this for (2)
#line "/dev/stdout" 1024
and if someone were to call bison with
bison -o /dev/stdout /dev/stdin
no doubt that (1) will become
#line "/dev/stdin" 42
Back your comment:
> That said, bison should be fixed to not emit this kind of line directives...
Well, I don't think we should decide whether or not to emit the
#lines based on how magic the input files, but if the consensus
here differs, I will change that. I personally do not understand
the point of not generating the output file and sending the output
directly to stdout. Especially in the case of Bison which also
might generate other files based on the base name of the output file
(/dev/stdout.h, /dev/stdout.output, etc.).
If you do think we should detect special input and output files
and not emit #line in their case, what kind of check would you
recommend?
That being said, since we also have caret-diagnostics, and we also support
#line in the input, we also have to get robust to users/generators
putting special file names in the #lines inside parser.y...
Cheers!
