<div dir="ltr">+djasper<div class="gmail_extra"><br>On Wed, Jul 31, 2013 at 5:40 PM, Vane, Edwin <span dir="ltr"><<a href="mailto:edwin.vane@intel.com" target="_blank">edwin.vane@intel.com</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Adding Manuel.<br>
<br>
-----Original Message-----<br>
From: Vane, Edwin<br>
Sent: Wednesday, July 31, 2013 11:40 AM<br>
To: Clang Dev List (<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>)<br>
Subject: RFC: YAML as an intermediate format for clang::tooling::Replacement data on disk<br>
<br>
Hi all,<br>
<br>
This discussion began on cfe-commits as the result of a commit (Tareq's poor header replacement patch that keeps getting reverted due to Windows build-bot issues). The start of the thread is here if you want background info: <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130729/084881.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130729/084881.html</a>.<br>

<br>
The proposal: The C++11 Migrator has a need to write Replacement data: offset, length, and replacement text, to disk. The replacement data describes changes made to a header while transforming one or more TU's. All the replacement data would be gathered up after an entire code-base is transformed by a separate tool and merged together to produce actual changes to headers. So the point is to serialize Replacement data as a form of inter-process communication using the file system as the communication link. Real inter-process communication is a possibility but not portable.<br>

<br>
YAML was suggested off-hand in some past patch discussion. Support for reading/writing YAML exists in LLVM. YAML is also meant for human-readable data serialization. It seems like a good choice.<br>
<br>
Another option that has been suggested is to just output diffs but as Manuel outlines in <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130729/084904.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130729/084904.html</a>, there are some major drawbacks to this technique.<br>

<br>
It's worth nothing we don't care to make these change description files full of serialized replacements available to general-purpose diff/merge tools. The only intended consumer is the C++11 Migrator Post-Processor. A prototype of this tool exists at <a href="https://github.com/revane/migmerge_git" target="_blank">https://github.com/revane/migmerge_git</a> but is soon to be replaced by a tool that has no third-party dependencies so it can live in clang-tools-extra with the migrator.<br>

<br>
Are there any other suggestions to address the flow of data between migrator and post-processor? Comments?<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>I think in the end we'll want 2 things:</div><div>- some functions in lib/Tooling/ that allow outputting those replacement collections from clang-tools</div><div>- a tool to aggregate, deduplicate and apply all the changes</div>
<div><br></div><div>Cheers,</div><div>/Manuel</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--<br>
Edwin Vane<br>
  Software Developer<br>
  Intel of Canada, Inc.<br>
<br>
<br>
</blockquote></div><br></div></div>