[cfe-dev] FW: RFC: YAML as an intermediate format for clang::tooling::Replacement data on disk

[Manuel Klimek]

On Wed, Jul 31, 2013 at 7:59 PM, Chandler Carruth <chandlerc at google.com>wrote:

>
> On Wed, Jul 31, 2013 at 8:49 AM, Manuel Klimek <klimek at google.com> wrote:
>
>> As noted, I think the design generally makes sense - my main concern is
>> that the tool that applies the replacements should not be
>> cpp11-migrator-specific. This would be useful for basically *all*
>> refactorings.
>>
>> I think in the end we'll want 2 things:
>> - some functions in lib/Tooling/ that allow outputting those replacement
>> collections from clang-tools
>> - a tool to aggregate, deduplicate and apply all the changes
>>
>
> Just to clarify an important design constraint from my perspective:
>
> It shouldn't be just any tool to aggregate, deduplicate, and apply all the
> changes. It should specifically be the *same* code path that a tool uses
> when it runs over all TUs in-process. This is to me *really* important to
> ensure we get consistent behavior across these two possible workflows:
>
> 1) Run tool X over code in a.cc, b.cc, and c.cc in a single invocation.
> Internally hands rewrites to a library in Clang that de-dups and applies
> the edits.
>
> 2) Run tool X over code in a.cc, b.cc, and c.cc; one invocation pre file.
> Each run writes out its edits in some form. Run tool Y which reads these
> edits and hands them to a library in Clang that de-dups and applies the
> edits.
>
>
> So, I essentially think that it *can't* be a separate system from Clang
> itself, it is intrinsically tied or it will yield different behavior (and
> endless confusion).
>

I agree in principle, but I think the common core should live in
lib/Tooling (and already does), and it's really really small (as it simply
deduplicates the edits, perhaps reports conflicts, and then just uses the
Rewriter to apply the changes - those are around 10 LOC).

Everything else in the extra tool is about reading the changes from disk,
and using multi-threading to apply them in a scalable way.

Cheers,
/Manuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130731/1175bf28/attachment.html>