llvm-project/llvm/lib/Support/ToolOutputFile.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

60 lines
1.8 KiB
C++
Raw Normal View History

//===--- ToolOutputFile.cpp - Implement the ToolOutputFile class --------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
//
// This implements the ToolOutputFile class.
//
//===----------------------------------------------------------------------===//
#include "llvm/Support/ToolOutputFile.h"
#include "llvm/Support/FileSystem.h"
#include "llvm/Support/Signals.h"
using namespace llvm;
[Support] Use outs() in ToolOutputFile 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. To make this possible, this patch changes the return type of llvm::outs() and errs() to raw_fd_ostream&. Previously the functions were constructing objects of that type, but returning a generic raw_ostream reference. This makes it possible for new ToolOutputFile and other code to use raw_fd_ostream methods like error() on the outs() object. This does not seem like a bad thing (since stdout is a file descriptor which can be redirected to anywhere, it makes sense to ask it whether the writing was successful or if it supports seeking), and indeed a lot of code was already depending on this fact via the ToolOutputFile "back door". Reviewers: dblaikie, JDevlieghere, MaskRay, jhenderson Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81078
2020-06-03 18:08:45 +08:00
static bool isStdout(StringRef Filename) { return Filename == "-"; }
ToolOutputFile::CleanupInstaller::CleanupInstaller(StringRef Filename)
: Filename(std::string(Filename)), Keep(false) {
// Arrange for the file to be deleted if the process is killed.
[Support] Use outs() in ToolOutputFile 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. To make this possible, this patch changes the return type of llvm::outs() and errs() to raw_fd_ostream&. Previously the functions were constructing objects of that type, but returning a generic raw_ostream reference. This makes it possible for new ToolOutputFile and other code to use raw_fd_ostream methods like error() on the outs() object. This does not seem like a bad thing (since stdout is a file descriptor which can be redirected to anywhere, it makes sense to ask it whether the writing was successful or if it supports seeking), and indeed a lot of code was already depending on this fact via the ToolOutputFile "back door". Reviewers: dblaikie, JDevlieghere, MaskRay, jhenderson Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81078
2020-06-03 18:08:45 +08:00
if (!isStdout(Filename))
sys::RemoveFileOnSignal(Filename);
}
ToolOutputFile::CleanupInstaller::~CleanupInstaller() {
[Support] Use outs() in ToolOutputFile 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. To make this possible, this patch changes the return type of llvm::outs() and errs() to raw_fd_ostream&. Previously the functions were constructing objects of that type, but returning a generic raw_ostream reference. This makes it possible for new ToolOutputFile and other code to use raw_fd_ostream methods like error() on the outs() object. This does not seem like a bad thing (since stdout is a file descriptor which can be redirected to anywhere, it makes sense to ask it whether the writing was successful or if it supports seeking), and indeed a lot of code was already depending on this fact via the ToolOutputFile "back door". Reviewers: dblaikie, JDevlieghere, MaskRay, jhenderson Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81078
2020-06-03 18:08:45 +08:00
if (isStdout(Filename))
return;
// Delete the file if the client hasn't told us not to.
[Support] Use outs() in ToolOutputFile 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. To make this possible, this patch changes the return type of llvm::outs() and errs() to raw_fd_ostream&. Previously the functions were constructing objects of that type, but returning a generic raw_ostream reference. This makes it possible for new ToolOutputFile and other code to use raw_fd_ostream methods like error() on the outs() object. This does not seem like a bad thing (since stdout is a file descriptor which can be redirected to anywhere, it makes sense to ask it whether the writing was successful or if it supports seeking), and indeed a lot of code was already depending on this fact via the ToolOutputFile "back door". Reviewers: dblaikie, JDevlieghere, MaskRay, jhenderson Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81078
2020-06-03 18:08:45 +08:00
if (!Keep)
sys::fs::remove(Filename);
// Ok, the file is successfully written and closed, or deleted. There's no
// further need to clean it up on signals.
[Support] Use outs() in ToolOutputFile 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. To make this possible, this patch changes the return type of llvm::outs() and errs() to raw_fd_ostream&. Previously the functions were constructing objects of that type, but returning a generic raw_ostream reference. This makes it possible for new ToolOutputFile and other code to use raw_fd_ostream methods like error() on the outs() object. This does not seem like a bad thing (since stdout is a file descriptor which can be redirected to anywhere, it makes sense to ask it whether the writing was successful or if it supports seeking), and indeed a lot of code was already depending on this fact via the ToolOutputFile "back door". Reviewers: dblaikie, JDevlieghere, MaskRay, jhenderson Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81078
2020-06-03 18:08:45 +08:00
sys::DontRemoveFileOnSignal(Filename);
}
ToolOutputFile::ToolOutputFile(StringRef Filename, std::error_code &EC,
sys::fs::OpenFlags Flags)
[Support] Use outs() in ToolOutputFile 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. To make this possible, this patch changes the return type of llvm::outs() and errs() to raw_fd_ostream&. Previously the functions were constructing objects of that type, but returning a generic raw_ostream reference. This makes it possible for new ToolOutputFile and other code to use raw_fd_ostream methods like error() on the outs() object. This does not seem like a bad thing (since stdout is a file descriptor which can be redirected to anywhere, it makes sense to ask it whether the writing was successful or if it supports seeking), and indeed a lot of code was already depending on this fact via the ToolOutputFile "back door". Reviewers: dblaikie, JDevlieghere, MaskRay, jhenderson Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81078
2020-06-03 18:08:45 +08:00
: Installer(Filename) {
if (isStdout(Filename)) {
OS = &outs();
EC = std::error_code();
return;
}
OSHolder.emplace(Filename, EC, Flags);
OS = OSHolder.getPointer();
// If open fails, no cleanup is needed.
if (EC)
Installer.Keep = true;
}
ToolOutputFile::ToolOutputFile(StringRef Filename, int FD)
[Support] Use outs() in ToolOutputFile 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. To make this possible, this patch changes the return type of llvm::outs() and errs() to raw_fd_ostream&. Previously the functions were constructing objects of that type, but returning a generic raw_ostream reference. This makes it possible for new ToolOutputFile and other code to use raw_fd_ostream methods like error() on the outs() object. This does not seem like a bad thing (since stdout is a file descriptor which can be redirected to anywhere, it makes sense to ask it whether the writing was successful or if it supports seeking), and indeed a lot of code was already depending on this fact via the ToolOutputFile "back door". Reviewers: dblaikie, JDevlieghere, MaskRay, jhenderson Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81078
2020-06-03 18:08:45 +08:00
: Installer(Filename) {
OSHolder.emplace(FD, true);
OS = OSHolder.getPointer();
}