[cfe-dev] C++11 migration tools

[Sam Panzer]

Thank you for giving a concrete proposal!

One other feature to add would be a degree of confidence for any given
change (Certain success, will probably work, risky), so that a command-line
flag could control how aggressive any transformations are. To be more
specific, one option is modeling the tool after diagnostics:
 - Transformations are grouped in a new tool, source-migrate
 - Each transformation should be named, so it can be turned on/off, such as
-range-for-loop or -noconst-expr
 - Each transformation should be grouped, so that all C++11 transformations
could be enabled or disabled in one go, e.g. -Tnocxx11
 - Each transformation should have some way to specify compiler
requirements, such as requiring C++ mode.

I think this is a good starting place for a code migration framework - I
will try setting up a tool with proper command-line flags.

-Sam


On Fri, Jun 29, 2012 at 9:09 AM, Douglas Gregor <dgregor at apple.com> wrote:

>
> On Jun 27, 2012, at 5:48 PM, Sam Panzer wrote:
>
> > Hi everyone,
> >
> > While it would be nice for everyone to start using C++11 right away,
> there is a huge volume of existing code that could also benefit from the
> new features. Just this week, someone offered a tool to add the override
> keyword to methods missing it, and I think we can expect more C++11-related
> refactoring tools in the near future. I think it would be a good idea to
> talk about how to coordinate similar efforts, which tools we would like to
> implement, what these tools should look like, and so on. As I'm new to
> Clang, your input will be especially useful for me, but a general
> discussion would probably benefit everyone working on something similar.
> >
> > Desirable features of a source translation system include:
> >  - Permitting work on parallel migration tools without blocking in
> either direction.
> >  - A system for naming these tools and optionally turning them off or
> on. This means we would need a system to resolve the order of changes
> should they interact.
> >  - A subsystem for setting parameters of these tools.
> >  - A possible interactive mode for decisions a tool can't make well
> (e.g. generated variable naming). This would be the first interactive
> component of Clang, I'm told.
> >  - A standard interface for these tools (e.g. they should be implemented
> as a FrontendAction, return tooling::Replacements, and can require that no
> errors occur during syntax checking).
> >  - A standard testing convention (e.g. both tests expecting conversions
> and tests expecting no change, to be run on the FrontendAction).
> >
> > 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?
>
> A C++11 migration tool is an excellent idea. Some specific suggestions:
>
>         - It should be based on the Tooling/Refactoring infrastructure:
> this is our way forward for building source-to-source translation tools,
> and we should use it for our own refactoring tools (especially new ones
> we're just starting on now). Tooling handles (or will handle) the
> nitty-gritty details of staging rewrites, de-duplicating rewrites that
> occur in headers, and making sure that the re-written source still parses
> afterward.
>
>         - It should be a single tool (C++11 migration) with a number of
> migration rules (for-each loops, override, nullptr), which we can expand
> over time. Just running the tool migrates everything we can, and it can
> have options for toggling individual features ("don't add override") or for
> targeting a specific common subset among compiles (migrate so that it works
> with Clang 3.1, GCC 4.6, and MSVC10). Bundling everything together makes
> for a much nicer user experience, because you write one command line and
> out pops a C++11 code-base.
>
>         - It should live in a separate repository of Clang tools alongside
> (but not a part of) the main Clang repository.
>
>         - It should "always" be good enough to take the LLVM+Clang
> codebase, translate it to C++11, then build a working compiler from that
> C++11 code-base. It's far better to have fewer/less aggressive transforms
> that never break code than it is to have eager transforms that do break
> code. And we have a perfect code-base to validate on.
>
> As a way forward, I think your tool to convert existing C++ for loops to
> the range-based for syntax would make a great first transformation, but we
> should put it into the tooling/refactoring context and label it as "the
> C++11 migration tool". Once the framework is in place, I bet other
> transformations would be contributed pretty quickly.
>
>         - Doug
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120629/d24ace41/attachment.html>