[cfe-dev] C++11 migration tools

[Sam Panzer]

In the interests of breaking up the commits for the migration tool, I have
prepared a skeleton for the executable, tests, and one of the
transformations. This should give us a concrete example to work with, along
with a place for me to commit changes as they begin to work reliably.

Thoughts?


On Mon, Jul 2, 2012 at 9:37 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Jul 2, 2012, at 11:25 AM, Douglas Gregor wrote:
> > 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...
>
> I'm assuming that this will eventually grow to include more than just a
> few modernizers...
>
> >> 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.
>
> Ok, I'm not going to fight strongly for this. :)  If you guys think that
> it makes sense to keep them all separate, that's cool with me.  If it turns
> out to be a bad idea in the future, they can always be merged at that point.
>
> -Chris
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120711/7339455b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cxxmigrate-skeleton.patch
Type: application/octet-stream
Size: 10027 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120711/7339455b/attachment.obj>