[cfe-dev] C++11 migration tools

[Douglas Gregor]

On Jun 30, 2012, at 8:35 AM, Chris Lattner wrote:

> How is it conceptually different than the Objective-C modernizer?

It isn't.

>  Why not have both in one tool?

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.

	- Doug


> -Chris
> 
> On Jun 29, 2012, at 2:48 PM, Douglas Gregor <dgregor at apple.com> wrote:
> 
>> 
>> On Jun 29, 2012, at 2:47 PM, Chandler Carruth <chandlerc at google.com> wrote:
>> 
>>> FWIW, I'm a bit hesitant about lumping *all* migrations into a single tool... My preference is for a tool that is at least somewhat focused on a migration domain -- in this case, C++11.
>> 
>> I completely misread the post I replied to. Yes, I agree with Chandler: the tool should be a C++11 migration tool, so it has a specific, coherent purpose. It should have options for adopting specific C++11 features.
>> 
>> 	- Doug
>> 
>>> On Fri, Jun 29, 2012 at 2:39 PM, Douglas Gregor <dgregor at apple.com> wrote:
>>> 
>>> On Jun 29, 2012, at 12:42 PM, Sam Panzer <panzer at google.com> wrote:
>>> 
>>> > Thank you for giving a concrete proposal!
>>> >
>>> > 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.
>>> 
>>> I don't think that we should admit any transformation unless we know that the resulting code type-checks. The tooling/refactoring stuff should provide that for us, and we'll need to be careful with some transformations (like the for-range loop transformation) that could break the semantics of the program if we're not careful. Migration tools aren't useful if they're going to break my code without telling me.
>>> 
>>> > To be more specific, one option is modeling the tool after diagnostics:
>>> >  - Transformations are grouped in a new tool, source-migrate
>>> >  - Each transformation should be named, so it can be turned on/off, such as -range-for-loop or -noconst-expr
>>> >  - Each transformation should be grouped, so that all C++11 transformations could be enabled or disabled in one go, e.g. -Tnocxx11
>>> >  - Each transformation should have some way to specify compiler requirements, such as requiring C++ mode.
>>> >
>>> > 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.
>>> 
>>> Yes, this seems completely reasonable.
>>> 
>>>        - Doug
>>> 
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>> 
>> 
>> _______________________________________________
>> 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/20120702/8d7aafd1/attachment.html>