[cfe-dev] RFC: Where to put new tool, related to C++11 Migrator, that has external deps

[Daniel Jasper]

I basically don't have much to add to what Manuel said. Just additional
thoughts why merge-tools won't be a generic solution:
1. You can't apply overlapping edits. With mergetools the lines can't
overlap. If you know the refactoring more precisely, you can get away with
the byte-ranges not overlapping. I don't consider this a must-have, but it
is definitely a disadvantage of merge-tools. However, the important fact
stands: You cannot apply overlapping edits either way.
2. A single refactoring step (e.g. turning a normal for-loop into a
range-based for loop) touches code at multiple places.
3. The conclusion of #1 and #2 together is that you need to guarantee that
a refactoring step is done atomically (either completely or not at all) and
I don't see a way to do that with merge tools.

Cheers,
Daniel


On Sat, Jul 6, 2013 at 9:13 AM, Manuel Klimek <klimek at google.com> wrote:

> +djasper, who has been doing some work in that area
>
> we definitely do not use any merge tools; they're imo mainly useful if you
> have unknown other changes, but in our case everything is known. Simply
> applying everything on a single Rewriter should do exactly what you want -
> the main problem is:
> - find a good on-disk representation
> - have a small program to slurp it in and apply the changes, if possible
> with multi-threading
>
> The reason we haven't contributed any of that upstream yet is:
> - need to learn how to do multi-threading with LLVM libs
> - need a good way to store the intermediate representation (probably
> should be YAML)
>
> Cheers,
> /Manuel
>
>
> On Fri, Jul 5, 2013 at 10:40 PM, Sean Silva <silvas at purdue.edu> wrote:
>
>> Manuel, didn't you guys at google deal with this issue with protobuf +
>> mapreduce? Do you guys have a simple way of merging the changes?
>>
>> -- Sean Silva
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130706/1dcaeeac/attachment.html>