[cfe-dev] C++11 migration tools
chandlerc at google.com
Fri Jun 29 02:45:25 PDT 2012
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?
>> On Thu, Jun 28, 2012 at 10:50 AM, Sam Panzer <panzer at google.com> wrote:
>>> I'm that intern :)
>>> 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
>>>> > 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:
>>>> John Wiegley
>>>> BoostPro Computing
>>>> cfe-dev mailing list
>>>> cfe-dev at cs.uiuc.edu
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev