[cfe-dev] C++11 migration tools

[Douglas Gregor]

On Jul 2, 2012, at 11:05 AM, Chris Lattner <clattner at apple.com> wrote:

> 
> On Jul 2, 2012, at 11:00 AM, Douglas Gregor wrote:
> 
>>>> 
>>>> Because that tool wouldn't have any focus. A "C++11 migrator" is something we can rally behind as a useful tool with an obvious scope, as is an "Objective-C modernizer". But a generic source migrator is an abstraction with no obvious usefulness or scope.
>>>> 
>>>> Obviously, these two tools will share nearly all of their infrastructure, except for the actual migration rules. And, in doing so, we'll demonstrate how best to create your own source-to-source translation tool.
>>> 
>>> I'm specifically thinking that they should be the same *executable* - of course they'd be different "tools" with different audiences.  The interface to the two tools should be virtually identical.  Why is it better to have an array of similar tools (that do different rewrites) as an array of executables instead of as a single executable with a mode switch?
>> 
>> 
>> Because different users want different tools. The two language migrators presumably aren't the only tools that would go into this side repository; should the eventual code-reformatting tool go into the same executable as well? Are you looking to optimize for build time here, or is there some other reason?
> 
> I'm trying to find the right level of abstraction here.   A similar argument could be that we should have one tool for each static analyzer checker, because some users would want one but not all checks.  

From a usage perspective, most users will want to run "the static analyzer" and get the default set of checks in one run. They may eventually fine-tune which checkers get run, but most won't, and they benefit from having all of the checkers bundled into one tool with an obvious purpose.

Similarly for the migration tools. Most users want to migrate to C++11, or migrate to modern Objective-C. The languages are different enough that it doesn't seem we'd benefit much from having one tool capable of migrating to modern Objective-ARC++11 in one shot… although you're wearing me down on that particular issue. A code "modernizer" that covers the various languages doesn't fall afoul of my justification below...

> What is the downside of having all the rewriters be in the same tool?

That tool has no obvious purpose or scope; it's just a grab bag of rewriters that happened to land in the tree. That's very hard to communicate to potential users. It also doesn't fit well with the tooling model, which intends to make it easier to build one-off, specialized tools, which are likely to be easier to use than a single executable with a pile of command-line options.

I do also worry about quality: it's far easier to qualify and test a specialized tool than it is to test all of the emergent combinations from an overly-general tool, especially if the robustness of various pieces varies wildly (which I expect it will). IIRC, the ARC migrator and ObjC modernizer needed some massaging to make all of the rewrites play nicely together, and that's a fairly small set of rules written by a very small number of people.

	- Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120702/0810770a/attachment.html>