This is an archive of the discontinued LLVM Phabricator instance.

[Support] Use outs() in ToolOutputFile
ClosedPublic

Authored by labath on Jun 3 2020, 3:22 AM.

Details

Summary

If the output filename was specified as "-", the ToolOutputFile class
would create a brand new raw_ostream object referring to the stdout.
This patch changes it to reuse the llvm::outs() singleton.

At the moment, this change should be "NFC", but it does enable other
enhancements, like the automatic stdout/stderr synchronization as
discussed on D80803.

I've checked the history, and I did not find any indication that this
class *has* to use a brand new stream object instead of outs() --
indeed, it is special-casing "-" in a number of places already, so this
change fits the pattern pretty well. I suspect the main reason for the
current state of affairs is that the class was originally introduced
(r111595, in 2010) as a raw_fd_ostream subclass, which made any other
solution impossible.

Another potential benefit of this patch is that it makes it possible to
move the raw_ostream class out of the business of special-casing "-" for
stdout handling. That state of affairs does not seem appropriate because
"-" is a valid filename (albeit hard to access with a lot of command
line tools) on most systems. Handling "-" in ToolOutputFile seems more
appropriate.

Diff Detail

Event Timeline

labath created this revision.Jun 3 2020, 3:22 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 3 2020, 3:22 AM
Herald added a subscriber: hiraditya. · View Herald Transcript

Thanks for looking at this. Having given it more thought, any side-effects this fix will have must be in the realm of bug fixes - if people were mixing printing to stdout from two different sources, they wouldn't expect potential stream interleaving after all.

Perhaps it's worth a simple unit test that shows that the result of ToolOutputFile.os() is the same as outs(), by comparing addresses? Not sure though.

llvm/include/llvm/Support/raw_ostream.h
501

I'm not sure I'm following the reason for changing from the base class here? I'm guessing it's to fit in well with ToolOutputFile's usage, but coudl that be changed to store a pointer to and return a raw_ostream easily?

llvm/lib/Support/ToolOutputFile.cpp
23

This logic seems to have been inverted?

labath updated this revision to Diff 268156.Jun 3 2020, 5:53 AM
labath marked 2 inline comments as done.
  • fix inverted condition
  • add test
  • replace std::unique_ptr with llvm::Optional
MaskRay accepted this revision.Jun 3 2020, 8:24 AM

LGTM.

llvm/include/llvm/Support/raw_ostream.h
501

&outs() is stored to raw_fd_ostream *ToolOutputFile::OS.

Some ToolOutputFile::os() call sites (lib/LTO/LTOCodeGenerator.cpp) use clear_error(), error(), etc, which requires a raw_fd_ostream

I think changing the return type to raw_fd_ostream & is fine.

This revision is now accepted and ready to land.Jun 3 2020, 8:24 AM
jhenderson accepted this revision.Jun 4 2020, 1:01 AM

LGTM, thanks!

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald Transcript