[PATCH] Driver: Include driver diags when we --serialize-diagnostics

[Richard Smith]

On Mon, Oct 20, 2014 at 3:19 PM, Justin Bogner <mail at justinbogner.com>
wrote:

> Richard Smith <richard at metafoo.co.uk> writes:
> > On Mon, Oct 20, 2014 at 10:43 AM, Justin Bogner <mail at justinbogner.com>
> wrote:
> >
> >     Currently, when --serialize-diagnostics is passed this only includes
> the
> >     diagnostics from clang -cc1, and driver diagnostics are dropped. This
> >     causes issues for tools that use the serialized diagnostics, since
> >     stderr is lost and these diagnostics aren't seen at all.
> >
> >     This patch handles this by merging the diagnostics from the CC1
> process
> >     and the driver diagnostics into a single file when the driver invokes
> >     CC1.
> >
> > The idea seems (superficially) reasonable to me. Have you tested this in
> the
> > case where the driver is given multiple input files to process? Please
> add a
> > test covering that case.
>
> Multiple input files don't DTRT with serialized diagnostics in the first
> place. I've just filed pr21318 about that.
>
> This doesn't make it worse (the driver diags *and* the last -cc1 will be
> included) and potentially makes that easier to fix, since the driver
> could be taught to merge after each execution. It looks to me that to
> actually do that work involves a fair amount of restructuring of the
> driver though.


OK, fair enough. I'll leave it to someone with more knowledge of
--serialize-diagnostics to approve this (or otherwise), though.

> What about the case where the clang driver runs a tool other than the
> clang
> > frontend? Your hypothetical process that runs clang with
> > --serialize-diagnostics and drops its stderr will lose diagnostics there
> too,
> > right?
>
> I'm not sure what you mean here. If the driver runs a tool that creates
> a serialized diagnostics file, this will merge it in. If the tool
> doesn't create a diagnostics file, the diagnostics will only include the
> driver's diags.
>

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 =)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141020/8ccc87cb/attachment.html>