Thank you for giving a concrete proposal!<div><br></div><div>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:</div>
<div> - Transformations are grouped in a new tool, source-migrate</div><div> - Each transformation should be named, so it can be turned on/off, such as -range-for-loop or -noconst-expr</div><div> - Each transformation should be grouped, so that all C++11 transformations could be enabled or disabled in one go, e.g. -Tnocxx11</div>
<div> - Each transformation should have some way to specify compiler requirements, such as requiring C++ mode.</div><div><br></div><div>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.</div>
<div><br></div><div>-Sam</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 29, 2012 at 9:09 AM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Jun 27, 2012, at 5:48 PM, Sam Panzer wrote:<br>
<br>
> Hi everyone,<br>
><br>
> 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.<br>
><br>
> Desirable features of a source translation system include:<br>
> - Permitting work on parallel migration tools without blocking in either direction.<br>
> - 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.<br>
> - A subsystem for setting parameters of these tools.<br>
> - 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.<br>
> - 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).<br>
> - A standard testing convention (e.g. both tests expecting conversions and tests expecting no change, to be run on the FrontendAction).<br>
><br>
> 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.<br>
><br>
> Thoughts? Suggestions?<br>
<br>
</div></div>A C++11 migration tool is an excellent idea. Some specific suggestions:<br>
<br>
- 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.<br>
<br>
- 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.<br>
<br>
- It should live in a separate repository of Clang tools alongside (but not a part of) the main Clang repository.<br>
<br>
- 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.<br>
<br>
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.<br>
<br>
- Doug<br>
<br>
</blockquote></div><br></div>