[cfe-dev] C++11 migration tools

[Douglas Gregor]

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