The C preprocessor informs the C compiler of the location in your source code where each token came from. Presently, this is just the file name and line number. All the tokens resulting from macro expansion are reported as having appeared on the line of the source file where the outermost macro was used. We intend to be more accurate in the future.
If you write a program which generates source code, such as the
bison parser generator, you may want to adjust the preprocessor's
notion of the current file name and line number by hand. Parts of the
bison are generated from scratch, other parts come
from a standard parser file. The rest are copied verbatim from
bison's input. You would like compiler error messages and
symbolic debuggers to be able to refer to
bison's input file.
bison or any such program can arrange this by writing
#line directives into the output file.
#line is a
directive that specifies the original line number and source file name
for subsequent input in the current preprocessor input file.
#line has three variants:
Previous versions of GNU CPP did not interpret escapes in
we have changed it because the standard requires they be interpreted,
and most other compilers do.
#line directives alter the results of the
__LINE__ predefined macros from that point on. See Standard Predefined Macros. They do not have any effect on
idea of the directory containing the current file. This is a change
from GCC 2.95. Previously, a file reading
#line 1 "../src/gram.y" #include "gram.h"
would search for
../src, then the
chain; the directory containing the physical source file would not be
searched. In GCC 3.0 and later, the
#include is not affected by
the presence of a
#line referring to a different directory.
We made this change because the old behavior caused problems when
generated source files were transported between machines. For instance,
it is common practice to ship generated parsers with a source release,
so that people building the distribution do not need to have yacc or
Bison installed. These files frequently have
referring to the directory tree of the system where the distribution was
created. If GCC tries to search for headers in those directories, the
build is likely to fail.
The new behavior can cause failures too, if the generated file is not
in the same directory as its source and it attempts to include a header
which would be visible searching from the directory containing the
source file. However, this problem is easily solved with an additional
-I switch on the command line. The failures caused by the old
semantics could sometimes be corrected only by editing the generated
files, which is difficult and error-prone.