<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 20, 2014 at 3:19 PM, Justin Bogner <span dir="ltr"><<a href="mailto:mail@justinbogner.com" target="_blank">mail@justinbogner.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> writes:<br>
> On Mon, Oct 20, 2014 at 10:43 AM, Justin Bogner <<a href="mailto:mail@justinbogner.com">mail@justinbogner.com</a>> wrote:<br>
><br>
>     Currently, when --serialize-diagnostics is passed this only includes the<br>
>     diagnostics from clang -cc1, and driver diagnostics are dropped. This<br>
>     causes issues for tools that use the serialized diagnostics, since<br>
>     stderr is lost and these diagnostics aren't seen at all.<br>
><br>
>     This patch handles this by merging the diagnostics from the CC1 process<br>
>     and the driver diagnostics into a single file when the driver invokes<br>
>     CC1.<br>
><br>
> The idea seems (superficially) reasonable to me. Have you tested this in the<br>
> case where the driver is given multiple input files to process? Please add a<br>
> test covering that case.<br>
<br>
</span>Multiple input files don't DTRT with serialized diagnostics in the first<br>
place. I've just filed pr21318 about that.<br>
<br>
This doesn't make it worse (the driver diags *and* the last -cc1 will be<br>
included) and potentially makes that easier to fix, since the driver<br>
could be taught to merge after each execution. It looks to me that to<br>
actually do that work involves a fair amount of restructuring of the<br>
driver though.</blockquote><div><br></div><div>OK, fair enough. I'll leave it to someone with more knowledge of --serialize-diagnostics to approve this (or otherwise), though.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> What about the case where the clang driver runs a tool other than the clang<br>
> frontend? Your hypothetical process that runs clang with<br>
> --serialize-diagnostics and drops its stderr will lose diagnostics there too,<br>
> right?<br>
<br>
</span>I'm not sure what you mean here. If the driver runs a tool that creates<br>
a serialized diagnostics file, this will merge it in. If the tool<br>
doesn't create a diagnostics file, the diagnostics will only include the<br>
driver's diags.<br>
</blockquote></div><br></div><div class="gmail_extra">My point is that a tool that drops stderr on the floor will also not work in lots of other cases. For instance, compiling with split-dwarf also runs objcopy, which might fail, and you'd not get an error message for that because it goes to stderr. Essentially, I was obliquely pointing out that this patch is addressing only a symptom and not the root cause, and whatever process you're fixing with this change may still be broken in the same way in other cases. You can fix the root cause by not discarding stderr =)</div></div>