<div dir="rtl"><div dir="ltr">Thanks, r244928 (clang + llvm), r244935+6 (<span style="font-size:12.8000001907349px">lldb).</span></div><div dir="ltr"><br></div></div><div class="gmail_extra"><div dir="ltr"><br><div class="gmail_quote">2015-08-13 20:56 GMT+03:00 David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 .8ex;border-left:1px #ccc solid;border-right:1px #ccc solid;padding-left:1ex;padding-right:1ex"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Aug 13, 2015 at 7:03 AM, Yaron Keren via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="rtl"><div dir="ltr">Ok, one more issue. I've removed the no-op resync() method and now getting rid of numerous raw_ostream::flush() calls. These were required before but now will never do anything but will waste runtime discovering that. </div><div dir="ltr">To find raw_svector_ostream::flush() calls speficially I locally shadowed raw_ostream:flush() with a deleted flush():<br></div><div dir="ltr"><br></div><div dir="ltr">class raw_svector_ostream {</div><div dir="ltr">...</div><div dir="ltr">public:</div><div dir="ltr">...</div><div dir="ltr"><div dir="ltr">  void flush() = delete;</div><div dir="ltr">};</div><div><br></div><div>so any direct use of raw_svector_ostream::flush() fails compilation. Calling raw_ostream:flush() itself would never reach the deleted function as it's not virtual, it will continue to function as before.</div><div><br></div><div>To explicitly prevent calling raw_svector_ostream::flush(), is that a good solution to commit?</div></div></div></blockquote></span><div><br>Seems reasonable to me - an alternative (that's probably worse) might be "using raw_ostream::flush" in the private section of raw_svector_ostream.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div dir="rtl"><div dir="ltr"><div><br></div><div><br></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote"><div dir="ltr">2015-08-13 16:53 GMT+03:00 Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span>:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 13 August 2015 at 04:17, Yaron Keren <<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>> wrote:<br>
> r244870 (with the change you requested), thanks!<br>
><br>
> I initially placed the virtual function in header since they were<br>
> one-liners.<br>
> The coding standards say that an anchor() function should be supplied, which<br>
> was indeed missing.  Other than required anchor function, why should the<br>
> virtual functions go in the .cpp?<br>
<br>
</span>Just because there is no advantage for most virtual methods to be in the .h.<br>
<span><br>
> Should I move the empty raw_svector_ostream destructor to the .cpp file too<br>
> as well?<br>
<br>
</span>Maybe. Destructors are the one exception since base class destructors<br>
call them non-virtually. If the class is final we can move them.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>
</div></div><br></span><span class="">_______________________________________________<br>
LLVM Developers mailing list<br>
</span><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>         <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></blockquote></div></div></div>