[cfe-dev] Stmt.getLocEnd() (Antoine Trouve)
Robert Ankeney
rrankene at gmail.com
Mon Feb 4 09:53:10 PST 2013
You might want to have a look at my CIrewriter.cpp example at
https://github.com/loarabia/Clang-tutorial which has some useful
information including:
// Note Stmt::getLocEnd() returns the source location prior to the
// token at the end of the line. For instance, for:
// var = 123;
// ^---- getLocEnd() points here.
SourceLocation END = s->getLocEnd();
// MeasureTokenLength gets us past the last token, and adding 1 gets
// us past the ';'.
int offset = Lexer::MeasureTokenLength(END,
ci->getSourceManager(),
ci->getLangOpts()) + 1;
SourceLocation END1 = END.getLocWithOffset(offset);
Rewrite.InsertText(END1, "\n}", true, true);
}
// Also note getLocEnd() on a CompoundStmt points ahead of the '}'.
// Use getLocEnd().getLocWithOffset(1) to point past it.
Robert Ankeney
On Mon, Feb 4, 2013 at 3:39 AM, <cfe-dev-request at cs.uiuc.edu> wrote:
> Send cfe-dev mailing list submissions to
> cfe-dev at cs.uiuc.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> or, via email, send a message with subject or body 'help' to
> cfe-dev-request at cs.uiuc.edu
>
> You can reach the person managing the list at
> cfe-dev-owner at cs.uiuc.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cfe-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: c++11 and invalid opcode (Piotr Madali?ski)
> 2. Static Analyzer symbolic execution path (Arthur Yoo)
> 3. basic block traversal for conditions and loops (Rajendra)
> 4. Re: Stmt.getLocEnd() (Antoine Trouve)
> 5. Re: Stmt.getLocEnd() (James Dennett)
> 6. Error in Tutorial for building tools using LibTooling and
> LibASTMatchers (Pedro Delgado Perez)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 04 Feb 2013 02:39:21 +0100
> From: Piotr Madali?ski <piotr at madtricks.pl>
> To: Sean Silva <silvas at purdue.edu>
> Cc: Clang <cfe-dev at cs.uiuc.edu>
> Subject: Re: [cfe-dev] c++11 and invalid opcode
> Message-ID: <510F1149.4060306 at madtricks.pl>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 04.02.2013 02:01, Sean Silva wrote:
> >> Your flip() function is causing undefined behaviour, as string::end()
> >> returns an iterator to the character *following* the last character of
> >> the string. Dereferencing that iterator is not allowed, you can only
> >> compare it against other iterators.
> > Where exactly does it dereference the off-the-end iterator?
> > std::reverse takes a half-open range.
> >
> > -- Sean Silva
> >
> >
> Right. I think, that the code is correct.
> The issue is probably some ABI-related problem on my machine.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 3 Feb 2013 00:25:56 +0800
> From: Arthur Yoo <phjy007 at gmail.com>
> To: cfe-dev at cs.uiuc.edu
> Subject: [cfe-dev] Static Analyzer symbolic execution path
> Message-ID:
> <
> CAEsbxu1ofbcujEV5LZEX7ySwqdquAqfb+9+oCOs4c_SBdagePg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi all,
>
> Recently I am working on developing a checker of Clang Static Analyzer.
> Because Clang Static Analyzer has a powerful symbolic execution engine, I
> choose Clang Static Analyzer as the platform for my work. My Checker mainly
> does some analysis work for C source code files. The checker will make use
> of the program states during its analysis execution and it will generate a
> report for each analysis.
>
> In my understanding, symbolic execution(Clang static analyzer) will cover
> all possible paths. For example, here is an sample source code which will
> be analyzed by static analyzer:
> 1 void func(int arg) {
> 2 int v;
> 3 if(arg > 0)
> 4 v = arg + 1;
> 5 else
> 6 v = arg + 999;
> 7 int a, b;
> 8 a = 99;
> 9 b = a;
> 10 }
> The symbolic execution path can be roughly represented as follow(based on
> ExplodedGraph):
> http://ww2.sinaimg.cn/large/a74ecc4cjw1e1fipmgpy5j.jpg
> And the execution sequence is 1-2-3-(1)-4-5. However, is there any possible
> means to change the execution sequence to be linear? That is to say, is
> there any possible means to change the execution sequence to be
> 1-2-(1)-4-5?
> Thanks for the help.
>
> ------
> Best regards,
> Arthur Yoo
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20130203/e9281502/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Mon, 04 Feb 2013 12:25:32 +0530
> From: Rajendra <rks at cse.iitb.ac.in>
> To: <cfe-dev at cs.uiuc.edu>
> Subject: [cfe-dev] basic block traversal for conditions and loops
> Message-ID: <74c363f94ce5642c3f1fccb88185905f at cse.iitb.ac.in>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hello,
>
> I am working for static analysis of C programs and I have CFG generated
> from Clang.
>
> I want to know how to traverse basic blocks for if-else and while loop
> - a common method that will work for both given a CFG.
>
> Is there any piece of Clang code I can make use of? or any pointers?
>
> Thank you.
>
> - Rajendra
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 4 Feb 2013 16:35:09 +0900
> From: Antoine Trouve <trouve at isit.or.jp>
> To: Jordan Rose <jordan_rose at apple.com>
> Cc: Antoine Trouve <trouve at isit.or.jp>, clang-dev Developers
> <cfe-dev at cs.uiuc.edu>
> Subject: Re: [cfe-dev] Stmt.getLocEnd()
> Message-ID: <EDAE486C-797E-4340-A469-328331C5C6B2 at isit.or.jp>
> Content-Type: text/plain; charset=iso-8859-1
>
> Le H.25/02/02 ? 2:28, Jordan Rose <jordan_rose at apple.com> a ?crit :
>
> >
> > On Feb 1, 2013, at 1:02 , Manuel Klimek <klimek at google.com> wrote:
> >
> >> On Fri, Feb 1, 2013 at 9:25 AM, Antoine Trouve <trouve at isit.or.jp>
> wrote:
> >> Hi everybody,
> >>
> >> I am now using LibTooling with the RefactoringTool to add some comments
> in some C codes.
> >>
> >> I am now trying to add comments after a given statement (the body of a
> for to say the truth);
> >> in order to detect the location of the end of a statement I use
> "Stmt.getLocEnd()", but I seems that its output is often inaccurate.
> >>
> >> Here are two examples, if I insert "/* HERE */" at the end location:
> >>
> >> for(i=0; i<N/2; i++) res +=mand(i,N/4/* HERE */);
> >> for(i=0; i<mand(N,N); i++) res /* HERE */++;
> >>
> >> I would expect the following output:
> >>
> >> for(i=0; i<N/2; i++) res +=mand(i,N/4);/* HERE */
> >> for(i=0; i<mand(N,N); i++) res ++;/* HERE */
> >>
> >> It looks like a bug. Am I right or did I miss something ?
> >>
> >> I found a previous recent discussion about this matter (
> http://clang-developers.42468.n3.nabble.com/Statements-that-end-with-td4028311.html),
> but It looks like nothing has been done.
> >>
> >> Yes, this is a known issue, and as far as I'm aware nothing has been
> done. We're usually working around this by looking for the next ';' token.
> >>
> >> I guess it's the good old "patches welcome" answer - or wait until it
> becomes important enough for somebody else to solve.
> >
> > The other issue here is that (by design) getLocEnd() doesn't actually
> return the SourceLocation just past the end of the statement, but the
> SourceLocation of the start of the last token in the statement. If you
> actually want the SourceLocation following the statement, you'll have to
> use Lexer::getLocForEndOfToken.
> >
> > Jordan
>
> I tried using "Lexer::getLoxForEndOfToken()", but that still wouldn't give
> the desired behaviour.
>
> For instance, for
>
> for(i=0; i<mand(N,N); i++) res /* HERE */++;
>
> It would now return the following location:
>
> for(i=0; i<mand(N,N); i++) res +/* HERE */+;
>
> The token is only the first "+", not the whole "++".
>
> I used the quick-and-dirty trick of Manuel, searching for the next ";",
> and that works. Still I feel insecure about this solution.
>
> Any idea to follow Jordan's proposal ? (so that I would get the location
> after the "++" and not only the first "+")
>
> Regards,
>
> - Antoine
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 4 Feb 2013 00:06:20 -0800
> From: James Dennett <james.dennett at gmail.com>
> To: Antoine Trouve <trouve at isit.or.jp>
> Cc: clang-dev Developers <cfe-dev at cs.uiuc.edu>
> Subject: Re: [cfe-dev] Stmt.getLocEnd()
> Message-ID:
> <CAKNGpgrSCw228E=DSu9B9Lt5z1ar9M=
> 2oJMaq1JevnCUrMMRNA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sun, Feb 3, 2013 at 11:35 PM, Antoine Trouve <trouve at isit.or.jp> wrote:
> > Le H.25/02/02 ? 2:28, Jordan Rose <jordan_rose at apple.com> a ?crit :
> >
> >>
> >> On Feb 1, 2013, at 1:02 , Manuel Klimek <klimek at google.com> wrote:
> >>
> >>> On Fri, Feb 1, 2013 at 9:25 AM, Antoine Trouve <trouve at isit.or.jp>
> wrote:
> >>> Hi everybody,
> >>>
> >>> I am now using LibTooling with the RefactoringTool to add some
> comments in some C codes.
> >>>
> >>> I am now trying to add comments after a given statement (the body of a
> for to say the truth);
> >>> in order to detect the location of the end of a statement I use
> "Stmt.getLocEnd()", but I seems that its output is often inaccurate.
> >>>
> >>> Here are two examples, if I insert "/* HERE */" at the end location:
> >>>
> >>> for(i=0; i<N/2; i++) res +=mand(i,N/4/* HERE */);
> >>> for(i=0; i<mand(N,N); i++) res /* HERE */++;
> >>>
> >>> I would expect the following output:
> >>>
> >>> for(i=0; i<N/2; i++) res +=mand(i,N/4);/* HERE */
> >>> for(i=0; i<mand(N,N); i++) res ++;/* HERE */
> >>>
> >>> It looks like a bug. Am I right or did I miss something ?
> >>>
> >>> I found a previous recent discussion about this matter (
> http://clang-developers.42468.n3.nabble.com/Statements-that-end-with-td4028311.html),
> but It looks like nothing has been done.
> >>>
> >>> Yes, this is a known issue, and as far as I'm aware nothing has been
> done. We're usually working around this by looking for the next ';' token.
> >>>
> >>> I guess it's the good old "patches welcome" answer - or wait until it
> becomes important enough for somebody else to solve.
> >>
> >> The other issue here is that (by design) getLocEnd() doesn't actually
> return the SourceLocation just past the end of the statement, but the
> SourceLocation of the start of the last token in the statement. If you
> actually want the SourceLocation following the statement, you'll have to
> use Lexer::getLocForEndOfToken.
> >>
> >> Jordan
> >
> > I tried using "Lexer::getLoxForEndOfToken()", but that still wouldn't
> give the desired behaviour.
> >
> > For instance, for
> >
> > for(i=0; i<mand(N,N); i++) res /* HERE */++;
> >
> > It would now return the following location:
> >
> > for(i=0; i<mand(N,N); i++) res +/* HERE */+;
> >
> > The token is only the first "+", not the whole "++".
>
> That sounds wrong; the token is definitely "++", not "+". What code
> are you using to find that it's a single "+"?
>
> -- James
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 4 Feb 2013 12:39:04 +0100 (CET)
> From: Pedro Delgado Perez <pedro.delgadoperez at mail.uca.es>
> To: cfe-dev at cs.uiuc.edu
> Subject: [cfe-dev] Error in Tutorial for building tools using
> LibTooling and LibASTMatchers
> Message-ID: <1922734252.3843.1359977944608.JavaMail.tomcat at draco>
> Content-Type: text/plain; charset="us-ascii"
>
>
> Hello everyone,
>
> I've been following the Tutorial for building tools using LibTooling and
> LibASTMatchers:
>
> http://clang.llvm.org/docs/LibASTMatchersTutorial.html [
> http://clang.llvm.org/docs/LibASTMatchersTutorial.html ]
>
> I didn't accomplish the Step 0 as I had followed the "getting started
> guide" before to get llvm and clang. Then, everything was right until I
> reached to the instruction:
>
> cmake -G Ninja ../llvm -DLLVM_BUILD_TESTS=ON
>
> Then, I got the next errors:
>
> > -- The C compiler identification is GNU 4.6.3
> > -- Check for working C compiler using: Ninja
> > -- Check for working C compiler using: Ninja -- works
> > -- Detecting C compiler ABI info
> > -- Detecting C compiler ABI info - done
> > -- The CXX compiler identification is GNU 4.6.3
> > -- Check for working CXX compiler using: Ninja
> > -- Check for working CXX compiler using: Ninja -- works
> > -- Detecting CXX compiler ABI info
> > -- Detecting CXX compiler ABI info - done
> > CMake Error at CMakeLists.txt:23 (include):
> > include could not find load file:
> >
> > VersionFromVCS
> >
> >
> > CMake Error at CMakeLists.txt:153 (include):
> > include could not find load file:
> >
> > AddLLVMDefinitions
> >
> >
> > CMake Error at CMakeLists.txt:239 (include):
> > include could not find load file:
> >
> > config-ix
> >
> >
> > CMake Error at CMakeLists.txt:247 (include):
> > include could not find load file:
> >
> > HandleLLVMOptions
> >
> >
> > -- Found PythonInterp: /usr/bin/python (found version "2.7.3")
> > -- Constructing LLVMBuild project information
> > CMake Error at CMakeLists.txt:306 (message):
> > Unexpected failure executing llvm-build: Usage: llvm-build [options]
> >
> >
> >
> > llvm-build: error: invalid native target: '' (not in project)
> >
> >
> > -- Configuring incomplete, errors occurred!
> >
> What's happening?
>
> By the way, the directory would be ../../llvm, wouldn't it? I'm in
> /usr/llvm/build and when I write ../llvm it says: "The source directory
> /usr/llvm/llvm does not exist"
>
> Thanks in advance,
>
> Pedro.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20130204/3bfb72a6/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
> End of cfe-dev Digest, Vol 68, Issue 10
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130204/af9d9c36/attachment.html>
More information about the cfe-dev
mailing list