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

[Manuel Klimek]

On Thu, Aug 1, 2013 at 3:06 PM, Vane, Edwin <edwin.vane at intel.com> wrote:

>
>
> > -----Original Message-----
> > From: Alex Rosenberg [mailto:alexr at ohmantics.com]
> > Sent: Thursday, August 01, 2013 1:32 AM
> > To: Vane, Edwin
> > Cc: Clang Dev List (cfe-dev at cs.uiuc.edu)
> > Subject: Re: [cfe-dev] RFC: YAML as an intermediate format for
> > clang::tooling::Replacement data on disk
>
> ...
>
> > I have wanted for some time for rewriter tools to use diff output that
> can be
> > used with existing review tools. If a merge tool is created that
> generates diff, I'd
> > probably be less concerned, but I'd still want a way to handle this
> self-contained
> > in the LLVM/Clang frameworks without a separate merge process.
>
> 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.
>
> 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.
>

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.


>
> >
> > Sent from my iPad
> >
> > On Jul 31, 2013, at 8:39 AM, "Vane, Edwin" <edwin.vane at intel.com> wrote:
> >
> > > Hi all,
> > >
> > > 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:
> > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-
> > 20130729/084881.html.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > Another option that has been suggested is to just output diffs but as
> Manuel
> > outlines in http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-
> > 20130729/084904.html, there are some major drawbacks to this technique.
> > >
> > > 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 https://github.com/revane/migmerge_git 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.
> > >
> > > Are there any other suggestions to address the flow of data between
> migrator
> > and post-processor? Comments?
> > >
> > > --
> > > Edwin Vane
> > >   Software Developer
> > >   Intel of Canada, Inc.
> > >
> > >
> > >
> > > _______________________________________________
> > > 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/20130801/e68447dc/attachment.html>