Re: #line %foo

[Akim Demaille]

>>>>> "Paul" == Paul Eggert <address@hidden> writes:

>> From: Akim Demaille <address@hidden> Date: 12 Nov 2002 10:21:44
>> +0100
>> 
>> Even if we want to support %line, we need #line.  This was asked
>> *years* ago.

Paul> OK, but then we should do the job consistently.  We should
Paul> accept the same syntax as C; currently we accept only a
Paul> restricted subset that cannot handle " within file names.

Agreed, I'll fix this.

Paul> More important, a #line directive should have the same effect
Paul> independently of whether it occurs in bracketed C code or in the
Paul> Yacc grammar.  Currently, #line has one meaning outside C code,
Paul> and quite a different meaning within C code: the latter doesn't
Paul> affect file names in Bison's diagnostics; the former does.

It is not that obvious at all:

exp: exp '+' exp
{
   /* Something. */
#line 123 "foo.y"
   $$ = $1 + $4;
}

should complain in foo.y:123.  But it is clear that the #line must be
forwarded inside the action.

Now, you seem to suggest that once the '}' closed, we should restore
the previous location context, which doesn't seem clear to me.  But
indeed, both attitudes seem to be defendable.  I don't think the
``complex'' one is more legitimate.


Paul> OK; but C's #line doesn't need to start in column 1, and it can
Paul> contain variable whitespace, comments, backslash-newline, etc.

Really!  I didn't know, sorry :(

Paul> Surely Bison's directive should be consistent with C if it uses
Paul> the same syntax.

I really don't think we need this.  After all, we are absolutely free
to decide what this extension is.  I'm really against supporting
tortured syntax which only concrete use will be the test suite.
Outputting a normal #line, straight, naked, à la 18th century seems
enough :)


[flex -p -p]
Paul> I guess we can live with it.  Maybe insert a comment.  Too bad
Paul> we can't use "\n" rather than "^".

After all, we can also decide to *parse* it as DASH_LINE INT STRING.
This will address all the issues while factoring the code.

We can do this with an intermediary parser between our scanner, and
the actual parser.  The reason why we might want a secondary parser is
that anyway, some day we want %if, %else, %endif.  Again, this is a
concrete demand from users (in particular the author of BTYacc).