[cfe-commits] [PATCH] PR6101: Preprocessor doesn't honor #line directives

[Chris Lattner]

On Apr 12, 2010, at 11:33 PM, Jordy Rose wrote:

> On Mon, 12 Apr 2010 21:33:20 -0700, Chris Lattner <clattner at apple.com>
> wrote:
>> On Apr 12, 2010, at 9:12 PM, Jordy Rose wrote:
>>> If !IsLineDirective (either of those cases), adding 1 to
>>> UserLoc.getLine()
>>> is incorrect -- we're actually entering or exiting a file instead of
> just
>>> reading a directive. Special-casing the main file isn't correct either;
>>> it
>>> also affects #includes.
>>> 
>>> I certainly don't like these contortions, but without adding an
>>> IsLineDirective parameter to the method, I'm not sure if there's a
> better
>>> way.
>> 
>> Is it possible to change the linemarker code to pass in the right
>> location?  I tried for a couple hours and couldn't get it right... I
>> stopped caring, and decided that this was a big enough improvement in
> the
>> status quo :)
>> 
>> -Chris
> 
> This seems to do it: passing the location /after/ the directive to the
> callback, instead of the location of the digit token. I think this still
> makes semantic sense: the "new file" starts after the line. And this is
> just for PPCallbacks; the real compiler still makes line notes the same way
> as before.
> 
> The one problem is when the very last line of a file is a #line directive
> or the return from an #include, and the file has no final newline. In these
> cases the emitted linemarker is off by one (since the lexer position can't
> advance to the next line). I included an XFAILing test case for this, but
> it probably doesn't matter: if we're at EOF, the directive won't affect any
> real code anyway!

Applied in r101226, I chose not to add the xfail test, because as you say, noone cares :)

Thanks!

-Chris