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

[Argyrios Kyrtzidis]

> On Oct 20, 2014, at 4:19 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> 
> On Mon, Oct 20, 2014 at 3:19 PM, Justin Bogner <mail at justinbogner.com <mailto:mail at justinbogner.com>> wrote:
> Richard Smith <richard at metafoo.co.uk <mailto:richard at metafoo.co.uk>> writes:
> > On Mon, Oct 20, 2014 at 10:43 AM, Justin Bogner <mail at justinbogner.com <mailto: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 =)

Stderr is not dropped on the floor, but you have to go in Xcode’s build log to see it; the diagnostic navigator only shows a generic ‘command failed’ error.
The diagnostic navigator has native support for clang diagnostics using the serialized diagnostic mechanism; by enhancing that mechanism we can get clang driver issues in the navigator and enhance it automatically.

I’ll comment on the patch soon(ish).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141020/4dfdfb7b/attachment.html>