<div dir="ltr">On Thu, Aug 1, 2013 at 3:06 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_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
> -----Original Message-----<br>
> From: Alex Rosenberg [mailto:<a href="mailto:alexr@ohmantics.com">alexr@ohmantics.com</a>]<br>
> Sent: Thursday, August 01, 2013 1:32 AM<br>
> To: Vane, Edwin<br>
> Cc: Clang Dev List (<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>)<br>
> Subject: Re: [cfe-dev] RFC: YAML as an intermediate format for<br>
> clang::tooling::Replacement data on disk<br>
<br>
...<br>
<br>
</div><div class="im">> I have wanted for some time for rewriter tools to use diff output that can be<br>
> used with existing review tools. If a merge tool is created that generates diff, I'd<br>
> probably be less concerned, but I'd still want a way to handle this self-contained<br>
> in the LLVM/Clang frameworks without a separate merge process.<br>
<br>
</div>This can still happen. What you're describing is orthogonal to this proposal about using YAML as an intermediate representation of serialized data between the migrator and replacement coalescing tool. I don't think anything here will block your desire from coming true.<br>

<br>
Speaking of JSON, this was suggested on IRC. It seems like it would be just as fine as YAML for this situation since there's no need for references or comments (yet, anyway). However, LLVM has no generic JSON parser, just a specific implementation for compilation databases. The YAML reader/writer that LLVM provides is completely generic and available right now even if it provides some features we don't need.<br>
</blockquote><div><br></div><div>Note that the compilation databases use the YAML parser. JSON is a subset of YAML. I'd also (slightly) prefer to use JSON over YAML for the intermediate representation.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
><br>
> Sent from my iPad<br>
><br>
> On Jul 31, 2013, at 8:39 AM, "Vane, Edwin" <<a href="mailto:edwin.vane@intel.com">edwin.vane@intel.com</a>> wrote:<br>
><br>
> > Hi all,<br>
> ><br>
> > This discussion began on cfe-commits as the result of a commit (Tareq's poor<br>
> header replacement patch that keeps getting reverted due to Windows build-bot<br>
> issues). The start of the thread is here if you want background info:<br>
> <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-</a><br>
> 20130729/084881.html.<br>
> ><br>
> > The proposal: The C++11 Migrator has a need to write Replacement data:<br>
> offset, length, and replacement text, to disk. The replacement data describes<br>
> changes made to a header while transforming one or more TU's. All the<br>
> replacement data would be gathered up after an entire code-base is<br>
> transformed by a separate tool and merged together to produce actual changes<br>
> to headers. So the point is to serialize Replacement data as a form of inter-<br>
> process communication using the file system as the communication link. Real<br>
> inter-process communication is a possibility but not portable.<br>
> ><br>
> > YAML was suggested off-hand in some past patch discussion. Support for<br>
> reading/writing YAML exists in LLVM. YAML is also meant for human-readable<br>
> data serialization. It seems like a good choice.<br>
> ><br>
> > Another option that has been suggested is to just output diffs but as Manuel<br>
> outlines in <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-</a><br>
> 20130729/084904.html, 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<br>
> serialized replacements available to general-purpose diff/merge tools. The only<br>
> intended consumer is the C++11 Migrator Post-Processor. A prototype of this<br>
> 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<br>
> replaced by a tool that has no third-party dependencies so it can live in clang-<br>
> tools-extra with the migrator.<br>
> ><br>
> > Are there any other suggestions to address the flow of data between migrator<br>
> and post-processor? Comments?<br>
> ><br>
> > --<br>
> > Edwin Vane<br>
> >   Software Developer<br>
> >   Intel of Canada, Inc.<br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > cfe-dev mailing list<br>
> > <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>