<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Thank you for reviewing!</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Wed, Jan 7, 2015 at 5:53 AM, <a href="mailto:kledzik@apple.com">kledzik@apple.com</a> <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">LGTM<br>
<br>
Two comments:<br>
<br>
1. This refactoring has taken so many steps, I'm beginning to think one big patch where we can see the end design might have been better...<br></blockquote><div><br></div><div>I'll upload my local branch to somewhere (maybe to github) so that you can see the final source tree there. For code review purpose, I think a series of small patches would be better.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. The ErrorFile concept makes me wonder if that should be the approach for all parseFile() implementations.  Rather than having a result parameter is that is a vector they append to and returning an error_code, they simply return a vector of Files and any errors are encoded as ErrorFiles in that vector.<br></blockquote><div><br></div><div>I agree. That's my plan.</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>
<a href="http://reviews.llvm.org/D6653" target="_blank">http://reviews.llvm.org/D6653</a><br>
<br>
EMAIL PREFERENCES<br>
  <a href="http://reviews.llvm.org/settings/panel/emailpreferences/" target="_blank">http://reviews.llvm.org/settings/panel/emailpreferences/</a><br>
<br>
<br>
</div></div></blockquote></div><br></div></div>