[llvm-commits] [LLVM, llvm-mc] bugfix for bug #10869: Unclear error for files without newline at the end of file (ARM, x86).

[Jim Grosbach]

I committed a slightly tweaked version as r139798. Thanks for the patch, this is a nice user-friendliness improvement to the asmparser.

-Jim


On Sep 14, 2011, at 1:09 PM, Stepan Dyatkovskiy wrote:

> Hi Jim,
> 
> Please find attached the regenerated patch with just the missing EOL changes, as requested.
> 
> Regards,
> Stepan.
> 
> 14.09.2011, 20:39, "Jim Grosbach" <grosbach at apple.com>:
>> Hi Stepan,
>> 
>> isAtStartOfLine is actually distinct from isAtStartOfStatement in exactly these ways. That is, it should only be true at an actual end-of-line, not every statement separator. For example, in the asm "nop ; nop\n", EndOfStatement would be returned twice when tokenizing, once for the ';' and once for the newline; however, isAtEndOfLine is set to true at the very beginning and after then newline, but not at the ';' separator.
>> 
>> You're absolutely right about it being a static. It should indeed be a private member instead. Fixed in r139697.
>> 
>> Can you re-generate your patch with just the missing EOL changes? It's much easier to review that way. Thanks!
>> 
>> -Jim
>> 
>> On Sep 14, 2011, at 2:47 AM, Stepan Dyatkovskiy wrote:
>> 
>>>  Hi Jim,
>>> 
>>>  Please find patch attached.
>>>  This patch contains another variant of bugfix. llvm-mc after this will report warning "Missed newline at the end of file".
>>> 
>>>  Few words about AsmLexer.cpp, LexToken method.
>>>  Here I found static variable IsAtStartOfLine (string #356). As I understood it is supposed that this flag should be true always when EndOfStatement is returned.
>>>  Is so, there are some missed cases:
>>>  1. Inside the LexToken method, "if (isAtStatementSeparator(TokStart)) {" branch. EndOfStatement is returned, but isAtStartOfLine is not changed.
>>>  2. Inside the LexComment... Should IsAtStartOfLine be static? It seems that it should be a private member...
>>>  I also fixed it in my patch.
>>> 
>>>  Regards,
>>>  Stepan<bugfix10869-with-warn.patch>
> <bugfix10869-ateof.patch>