> On Oct 20, 2014, at 4:19 PM, Richard Smith <[email protected]> wrote:
>
> On Mon, Oct 20, 2014 at 3:19 PM, Justin Bogner <[email protected]
> <mailto:[email protected]>> wrote:
> Richard Smith <[email protected] <mailto:[email protected]>> writes:
> > On Mon, Oct 20, 2014 at 10:43 AM, Justin Bogner <[email protected]
> > <mailto:[email protected]>> 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).
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
