[cfe-dev] C++11 migration tools

[Chandler Carruth]

I tend to agree that this should use the Tooling/Refactoring stuff.

However, I'm curious about the best way to structure the location of
migration candidates: AST matchers vs. visitor.

I can almost see the visitor pattern working really well here as each
different construct can have a pile of migration logic dropped in.... But
if there is a need to connect dots between more distant constructs, that
wouldn't work so well.... Not at all sure what would be best here.


On Fri, Jun 29, 2012 at 1:37 AM, Manuel Klimek <klimek at google.com> wrote:

> On Fri, Jun 29, 2012 at 4:06 AM, Sam Panzer <panzer at google.com> wrote:
>
>> In case anyone wanted to take a look, the attached patch includes the
>> tool I've been working on. I create a new binary, c++migrate, which
>> attempts to convert for loops in the source files given to it. Most of my
>> focus has been on the FrontedAction, so I skirted all of the issues
>> mentioned above by keeping the frontend interaction minimal (i.e. I just
>> call Tooling::ClangTool::run), and the changes are just reported on
>> standard output, if there are any to be made.
>>
>> The tool can currently convert for loops that range over (1) statically
>> allocated arrays, and (2) Clang-style iterator-based loops (with begin and
>> end iterators defined). All loop variables need to be declared within the
>> loop's initialization step in order for it to be converted, though this
>> requirement can potentially be eliminated. I'm working on converting
>> iterator-based loops that call someContainer.end() on each iteration, since
>> they're probably the common case in many codebases.
>>
>> Just for fun, I ran the tool over the 41 .cpp files in lib/Sema, and my
>> tool found 71 convertible loops in 17 files. There is plenty more work to
>> go, because it clearly missed some easy ones.
>>
>> Any input or feedback is welcome!
>>
>
> High-level observations:
> 1. the handling of the rewrites; any reason not to use the
> Tooling/Refactoring stuff? Currently in the patch it looks to me like the
> files are not rewritten, but dumped to stdout
> 2. is the reason not to use the matchers here that they're not landed in
> mainline yet?
>
> Cheers,
> /Manuel
>
>
>>
>> -Sam
>>
>> On Thu, Jun 28, 2012 at 10:50 AM, Sam Panzer <panzer at google.com> wrote:
>>
>>> I'm that intern :)
>>>
>>> -Sam
>>>
>>>
>>> On Wed, Jun 27, 2012 at 9:48 PM, John Wiegley <johnw at boostpro.com>wrote:
>>>
>>>> >>>>> Sam Panzer <panzer at google.com> writes:
>>>>
>>>> > In particular, I am working on a tool to convert existing C++ for
>>>> loops to
>>>> > take advantage of the new C++11 range-based syntax. I can imagine
>>>> similar
>>>> > tools to replace const with constexpr, macro hacks with
>>>> static_assert, and
>>>> > potentially other common refactorings.
>>>>
>>>> > Thoughts? Suggestions?
>>>>
>>>> You really must watch this presentation, if you haven't already:
>>>>
>>>>     http://www.youtube.com/watch?v=yuIOGfcOH0k
>>>>
>>>> --
>>>> John Wiegley
>>>> BoostPro Computing
>>>> http://www.boostpro.com
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>>
>>>
>>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>
> _______________________________________________
> 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/20120629/c8fe9f12/attachment.html>