rrankene at gmail.com
Wed Feb 6 08:36:54 PST 2013
Keep in mind that the body of a for statement can be not only a
CompoundStmt ending in tok::r_brace, but any statement, including another
"for" statement, which in turn could end in either a semicolon or brace.
As I recall, getLocEnd in any of these cases will point to the token before
either the ";" or the "}", but you might want to check that. And you can
probably check the result of loc = Lexer::findLocationAfterToken(...) for
loc.isValid() to see if the token was indeed found there.
It seems like some generic Stmt call such as getLocForEndOfStmt() would
really be useful.
> > On Feb 4, 2013, at 17:37 , Antoine Trouve <trouve at isit.or.jp> wrote:
> >> My bad, I was using the function the wrong way.
> >> But I noticed that I couldn't go through a semicolon using
> "Lexer::getLocForEndOfToken" if there is a space before the semicolon.
> >> For instance, let's consider this code:
> >> for(i=0; i<mand(N,N); i++) res ++ ;
> >> Initially, the SourceLocation retreieved with "getLocEnd()" is before
> the "++":
> >> for(i=0; i<mand(N,N); i++) res /*HERE*/++ ;
> >> If I call "Lexer::getLocForEndOfToken", it will point to after "++":
> >> for(i=0; i<mand(N,N); i++) res ++/*HERE*/ ;
> >> Then if I call again getLocForEndOfToken, the result will point to the
> exact same location (I need to call "getLocWithOffset")
> >> for(i=0; i<mand(N,N); i++) res ++/*STILL HERE*/ ;
> >> In the case I don't have any space before the semicolon, the return
> value of the second call to getLocForEndOfToken will point to after it:
> >> for(i=0; i<mand(N,N); i++) res ++;/*HERE*/
> >> (no space before the ";")
> >> Is that the expected behaviour ? I find it pretty annoying in my very
> situation because I have no choice but looping with
> "SourceLocation::getLocWithOffset" until I find a ";".
> > Hm. It's expected behavior because an Expr can be nested inside other
> Exprs, in which case you only want the beginning and end of the Expr to
> include the expression itself. Consider "a + b * c;" The semicolon is not
> part of "b * c"; you could argue it's part of "a + b * c", but that's not
> consistent. On the other hand, we otherwise don't track the location of the
> semicolon anywhere.
> > I can see this being an actual deficiency we want to fix; if you're
> interested in pursuing this, please file a bug report at
> http://llvm.org/bugs/. Meanwhile, Lexer::findLocationAfterToken will
> probably be a more resilient way to find the semicolon.
> Yes, the behaviour is not consistent to my point of view. I'll file a bug
> Anyway, I'm using "findLocationAfterToken" as you suggested and it works
> like a charm: thank you for your help !
> - Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev