Richard Smith <[email protected]> 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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
