[cfe-dev] Bug: Lexer::getLocForEndOfToken() returns a position too far for a token which include backslash-newline pairs

[Ted Kremenek]

What is the impact on performance here (if any)?

On Apr 5, 2011, at 6:41 AM, Marcin Kowalczyk wrote:

> On Mon, Apr 4, 2011 at 7:27 PM, John McCall <rjmccall at apple.com> wrote:
> 
> >> I guess that MeasureTokenLength() includes any backslash-newline
> >> pairs, but AdvanceToTokenCharacter() skips them. I'm not sure in which
> >> direction this should be fixed.
> >
> > I *think* the right solution here is for getLocForEndOfToken to just use
> > getFileLocWithOffset instead of AdvanceToTokenCharacter.  Would
> > you mind writing that up and testing it?
> 
> Yes, results look fine with this change.
> 
> --- /tmp/g4-89926/cache/depot/google3/third_party/llvm/trunk/tools/clang/lib/Lex/Lexer.cpp#33	2011-03-22 01:58:24.000000000 +0100
> +++ /home/qrczak/qrczak-janitor/google3/third_party/llvm/trunk/tools/clang/lib/Lex/Lexer.cpp	2011-04-05 13:02:09.557044000 +0200
> @@ -674,7 +674,7 @@
>   else
>     return Loc;
>   
> -  return AdvanceToTokenCharacter(Loc, Len, SM, Features);
> +  return Loc.getFileLocWithOffset(Len);
> }
> 
> //===----------------------------------------------------------------------===//
> 
> -- 
> Marcin Kowalczyk
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110405/6d431b11/attachment.html>