<div dir="ltr">On Wed, Jul 31, 2013 at 6:33 PM, Du Toit, Stefanus <span dir="ltr"><<a href="mailto:stefanus.du.toit@intel.com" target="_blank">stefanus.du.toit@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>
On Wed, Jul 31, 2013 at 5:40 PM, Vane, Edwin <<a href="mailto:edwin.vane@intel.com">edwin.vane@intel.com</a><mailto:<a href="mailto:edwin.vane@intel.com">edwin.vane@intel.com</a>>> wrote:<br>
-----Original Message-----<br>
From: Vane, Edwin<br>
Sent: Wednesday, July 31, 2013 11:40 AM<br>
</div><div class="im">To: Clang Dev List (<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><mailto:<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>
</div>I have to wonder whether it's not easier to just ensure that headers are only transformed once.<br>
<br>
I understand there's the issue of deciding what compiler flags to use when processing a header. My thoughts on that:<br>
* For some projects, there aren't any per-file compiler flags, so it would be sufficient to just pass a general set of flags to the tool on the command line (e.g., with made up parameter syntax, something like 'cpp11-migrate *.h —compile-flags="-I../include –DFOO"'…)<br>
* For other projects, a simple heuristic of matching "foo.{cpp,cc,cxx,…}" to "foo.{h,hh,hpp,…}" might be enough (lots of details to sort out here, like how to specify the directory structure, but hopefully you get the idea)<br>
* For more complicated cases, one could add (whether manually or using some tool) entries to the compilation database for header files<br>
<br>
With that in mind, why not treat header files like source files and process them separately?<br></blockquote><div><br></div><div>How do you propose to treat template instantiations?</div><div><br></div><div>For example:</div>
<div>a.h:</div><div>template <typename T> class A { void x(T t) { t.y(); }}</div><div><br></div><div>x.cc:</div><div>A<C> a; a.x();</div><div><br></div><div>Imagine we want to change C::y -> C::z. Now depending on which types A is instantiated with, it might be totally safe to refactor t.y() in A or not. So there needs to be a postprocessing step that figures that out anyway.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If the issue is parallel compilation, deferring the replacements makes perfect sense as a way to resolve any read-write conflicts (transforming one header while it's being parsed as part of another TU). However, if you ensure that a header isn't touched by multiple transformations, and generally ensure that transformations don't clobber each other by design, there's no need to merge anything.<br>
<br>
Personally I would even accept a slightly more limited set of transformations in exchange for never having to worry about merging.<br></blockquote><div><br></div><div>"Merging" is usually merely deduplication, which is not hard. I have the feeling that you think there's lots of complexity where it isn't. I'd definitely say that the heuristics you propose in order to be able to process headers on their own are much higher than the issue of deduplicating edits.</div>
<div><br></div><div>Cheers,</div><div>/Manuel</div></div></div></div>