[cfe-dev] C++11 migration tools

[David Blaikie]

On Wed, Jun 27, 2012 at 5:48 PM, Sam Panzer <panzer at google.com> 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?

One thing I've been wondering is:

How do we preserve these invariants once we've established them? In
the case of something like the override-adding migration it seems like
that could be implemented as a trivial style checker, enforced at
compile time once you migrate the codebase - and with a builtin fixit.
Once you have such a style checker, the migration is really just a
matter of running the style checker in auto-fix mode - at which point
there's no need for an explicit migration tool.

I'm not sure if this is true of the for loop-ifier, though - I assume
it might be too expensive to run at compile time as a style
enforcement/auto-formatter. (though we have the for condition warning
in-place now that's doing work across the body of a for loop - so
perhaps such a check isn't too expensive to do up-front on every
build)

- David