[PATCH] Driver: Include driver diags when we --serialize-diagnostics
Justin Bogner
mail at justinbogner.com
Mon Oct 20 17:04:57 PDT 2014
Richard Smith <richard at metafoo.co.uk> writes:
>>> 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 =)
Ah, I see what you mean. This actually handles that (to a degree). The
driver already emits a diagnostic like "objcopy failed" when a tool
fails, and this fix means that *that* diagnostic will show up in the
serialized diags. Without this change it doesn't.
I agree that completely dropping stderr is usually a bad idea. In
something like an IDE, though, it's useful to have the information
available in a structured way whether or not you show stderr to the
user.
More information about the cfe-commits
mailing list