[cfe-dev] Qt 4 to Qt 5 porting tool with the tooling branch
steveire at gmail.com
Mon Jun 18 07:13:39 PDT 2012
Manuel Klimek wrote:
> Hi Stephen,
> first, really cool blog post, and thanks for providing feedback & docs and
> helping us making the tools more awesome - we really appreciate this!
No problem. Clang based porting tools is a cool party :).
>> After that, the matches are actually nested function calls (the
>> capitalisation style for functions seems funny to use Qt developers).
> Yea, that's not set yet - please chime in with your color of the bikeshed
> on the review thread for the ast matchers ;) I seriously don't care, so I
> want people who care about one way or the other to jump in with good
> arguments of why their preferred way is superior :D
Is the review thread on cfe-commits? I'm not really familiar with how
reviews are done in this community yet. Does this mean that the content of
the branch is being rebased and applied to trunk?
I don't think I'll jump in on this bikeshed aspect though :). The case is
something I noted for colleagues who use Qt all day, where the convention is
methods/functions = lowercase first letter. If you want to be 'compatible'
with Qt, they would need to be changed, but otherwise it's not important :).
>> [End copy-paste]
> All accurate.
>> I was also wondering if there is an easy way to only modify the code
>> inside the repo and not included headers? In my tool I require the user
>> to pass the
>> source-dir on the command line, and then manually check paths to see if
>> are below it, but this is error-prone.
> If with "manually", you mean "do a regexp match on the path", then yep,
> that's what I also do.
> Why is that error prone?
There could be aspects of relative/absolute paths, symlinks, os-specific
issues, bugs in the regexp, etc.
>> Additionally, many of the concepts I encoded are generic, not Qt specific
>> (such as renaming methods, enums etc). It seems that these could be re-
>> usable, so we could either add some version of this to the clang
>> examples, and/or see if we can define a higher level collection of ways
>> to refactor the code. I presume google also has some collection/repo of
>> such things already?
> Unfortunately not. Most of the engineers using those tools at Google have
> pretty non-standard and complex problems, at which point other costs start
> to dwarf writing the matchers and replacements.
> But we are starting to work on a more principled approach that includes
> ready-made refactorings, targeted towards small scale use cases ("I want
> to rename what is under my cursor", we actually have a prototype for this
> in the branch).
The ClangRename example?
Yes, that's also useful in the context of an IDE I think, but in terms of
our goals of a 'fire and forget' tool that does the boring parts of a
porting job, it's not really so important to rename things by symbol under
cursor or at a location in a file.
>> Finally, the suggestion here:
>> was not quite what I needed to use to correctly match the code used. The
>> matcher I used was this:
>> BindTemporaryExpression(has(Id("ctor", ConstructorCall()))),
>> Id("operator", OverloadedOperatorCall()),
>> Id("ctor", ConstructorCall()),
>> Id("expr", Expression())
>> So I had to add some extra BindTemporaryExpression() into the expression
>> which I would have preferred to be automatic, like I think some implicit
>> cast stuff is.
> Yep, the temporary stuff is not yet perfect. Ideas welcome, preferably
> when we have it in mainline ;) (there's a review thread currently open -
> afaik nobody answered yet).
I'd like to have a look if you can link it.
More information about the cfe-dev