<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Okay, thank you guys!<br>
It seems that I could solve my problem!<br>
<br>
<br>
<blockquote type="cite">
<div>Usually we just use the lexer towards the "," from the end
of the parameter... (you know how many there are, so you know
whether there is going to be a comma or not)</div>
</blockquote>
Finally, a question for Manuel :-)<br>
Sorry for bothering you but exploring and understanding clang
techniques is exiting!<br>
<br>
Why do you use the lexer? <br>
Something like this could make it hard to find the correct comma:<br>
<br>
void foo (int i /* comment , , , , */, /* , , , , */ int j /*
,,,*/, /* ,,,, */ int k);<br>
<br>
Cheers!<br>
<br>
Joshua<br>
<br>
On 09/10/2013 07:17 AM, Manuel Klimek wrote:<br>
</div>
<blockquote
cite="mid:CAOsfVvmjhMXDJ1Qtz6QA2aYvFf+Xn_s5S8mtkkJWvjq5W9yT=A@mail.gmail.com"
type="cite">
<div dir="ltr">On Tue, Sep 10, 2013 at 9:39 AM, Guillaume Papin <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:guillaume.papin@epitech.eu" target="_blank">guillaume.papin@epitech.eu</a>></span>
wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">You are
probably interested by a ParmVarDecl.<br>
<br>
If you need the type you can use:<br>
<br>
ParmVarDecl->getTypeSourceInfo()->getTypeLoc()<br>
<br>
A fairly recent transform in clang-modernize rewrites the
type of some<br>
parameters, you can take a look. The interesting stuff for
you is<br>
located in
clang-modernize/PassByValue/PassByValueActions.cpp I
think.<br>
<br>
I don't know if you can get the comma directly but I'm
sure you can find<br>
a way to delete a parameter anyway.<br>
</blockquote>
<div><br>
</div>
<div>Usually we just use the lexer towards the "," from the
end of the parameter... (you know how many there are, so
you know whether there is going to be a comma or not)</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb">
<div class="h5"><br>
Joshua T <<a moz-do-not-send="true"
href="mailto:llvm.mailing@gmail.com">llvm.mailing@gmail.com</a>>
writes:<br>
<br>
> Hello Eli, Manuel,<br>
><br>
><br>
> thanks for the pointer to clang-modernize.<br>
><br>
> 4. rewriting text is easy - in fact, we've
written a whole library as part<br>
> of clang (libTooling) to make it as easy as
possible; the tools you find in<br>
> clang's extra tools repository are written on
top of that architecture<br>
><br>
> Okay, I see that the rewriter must be a really
powerful tool.<br>
><br>
> Based on my second example, deleting a function
parameter in a FunctionDecl.<br>
> Is there any way to get the source location of
the comma between two parameters?<br>
> I'm happy about every evidence :-) I didn't find
something like ParmTypeLoc<br>
> or getParmLoc()....<br>
><br>
><br>
> Cheers!<br>
><br>
> Joshua<br>
><br>
><br>
> On 09/09/2013 01:58 PM, Eli Friedman wrote:<br>
><br>
> On Mon, Sep 9, 2013 at 1:30 PM, Manuel Klimek
<<a moz-do-not-send="true"
href="mailto:klimek@google.com">klimek@google.com</a>>
wrote:<br>
><br>
><br>
><br>
><br>
> On Mon, Sep 9, 2013 at 6:06 PM, Joshua T
<<a moz-do-not-send="true"
href="mailto:llvm.mailing@gmail.com">llvm.mailing@gmail.com</a>>
wrote:<br>
><br>
><br>
><br>
> Hello Manuel,<br>
><br>
> I’m dealing with the same issue like
maxs.<br>
><br>
><br>
> >> Generally speaking, the easy
way is to add it in the code and let<br>
> clang<br>
> >> parse the code (seriously,
that's what works best, and has a<br>
> couple of<br>
> >> other upsides - you can also
do that programatically).<br>
><br>
><br>
> Do you prefer this workflow:<br>
><br>
> 1. Add new lines into the buffer<br>
> 2. Reparse the buffer and
generate a complete new tree?<br>
><br>
> That seems like a really heavy
workload for adding something new.<br>
> What are the other upsides? Sorry,
I’m new to the Clang-API world :<br>
> (.<br>
><br>
><br>
><br>
> It's not actually a "heavy" workflow -
clang has some libraries that<br>
> help making that workflow amazingly
little code. You can look at<br>
> clang-modernize, which uses exactly this
procedure to migrate code to<br>
> c++11 (and beyond ;)<br>
><br>
> <br>
><br>
><br>
> >> Or to turn it around, the
other question would be: why do you<br>
> want to add<br>
> >> a function to the AST
instead of adding it to the code? :)<br>
><br>
><br>
> Easy :-) I can add every line of code
via the Rewriter class,<br>
> however, it is<br>
> challenging to guarantee that my
insertion is valid. For instance, I<br>
> could<br>
> add this function: void foo(int a,
int b int c) without any problem…<br>
> Besides syntax errors semantic errors
can happen. For instance, a<br>
> function<br>
> with the same name and same parameter
list exists already in the<br>
> scope…<br>
><br>
> On the other hand, inserting directly
into the tree means that we<br>
> can<br>
> evaluate the expression.<br>
> After the AST safeguards that
everything is fine, we only have to<br>
> use pretty<br>
> print function.<br>
><br>
> Okay, another example:<br>
><br>
> Lets say we would like to change the
number of arguments of a<br>
> FunctionDecl<br>
> by deleting one argument.<br>
> We make the assumption that at least
one argument is in the<br>
> parameter list.<br>
><br>
> Text editing requires a lot of
effort.<br>
> If the function has one parameter, we
can use the start and end<br>
> location of<br>
> the parameter. No big deal.<br>
> If the function has many arguments,
it is more complicated. We have<br>
> to<br>
> delete the parameter like before and
have to figure out the position<br>
> of the<br>
> corresponding comma.<br>
><br>
> Doing this by editing the AST is much
more simpler. Delete the<br>
> argument in<br>
> the AST and call pretty print, right?
Comma handing is the job of<br>
> pretty<br>
> print, right?<br>
><br>
><br>
><br>
> Unfortunately this is not true.<br>
> 1. inserting a node in the AST will not
automatically "validate" it -<br>
> afaik clang relies on its C++ analysis in
Sema to only run into building<br>
> correct ASTs; you can still add nodes to
the AST, if you're really<br>
> careful<br>
> 2. the AST has undocumented invariants,
so you might run into problems<br>
> later that you don't even know of now<br>
> 3. clang doesn't come with a
pretty-printer that actually outputs "real<br>
> code" (at least if I'm not completely
missing something) - the pretty<br>
> printers I know are made for debugging or
diagnostics <br>
><br>
><br>
> Actually, we do have such a pretty-printer...
it just isn't good enough for<br>
> production use. :) Try "clang -cc1
-ast-print".<br>
><br>
><br>
> -Eli<br>
><br>
><br>
><br>
<br>
</div>
</div>
<span class="HOEnZb"><font color="#888888">--<br>
Guillaume Papin<br>
</font></span>
<div class="HOEnZb">
<div class="h5"><br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>