Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4 |
|
#
03ffb82c |
| 09-Apr-2024 |
Haohai Wen <haohai.wen@intel.com> |
[Support] Make CleanupInstaller public (NFC) (#86758)
This can be used by others to automatically remove temp files.
|
Revision tags: llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6 |
|
#
1f914944 |
| 22-Nov-2022 |
Kazu Hirata <kazu@google.com> |
Don't use Optional::getPointer (NFC)
Since std::optional does not offer getPointer(), this patch replaces X.getPointer() with &*X to make the migration from llvm::Optional to std::optional easier.
Don't use Optional::getPointer (NFC)
Since std::optional does not offer getPointer(), this patch replaces X.getPointer() with &*X to make the migration from llvm::Optional to std::optional easier.
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
Differential Revision: https://reviews.llvm.org/D138466
show more ...
|
Revision tags: llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3 |
|
#
75e164f6 |
| 20-Jan-2022 |
serge-sans-paille <sguelton@redhat.com> |
[llvm] Cleanup header dependencies in ADT and Support
The cleanup was manual, but assisted by "include-what-you-use". It consists in
1. Removing unused forward declaration. No impact expected. 2. R
[llvm] Cleanup header dependencies in ADT and Support
The cleanup was manual, but assisted by "include-what-you-use". It consists in
1. Removing unused forward declaration. No impact expected. 2. Removing unused headers in .cpp files. No impact expected. 3. Removing unused headers in .h files. This removes implicit dependencies and is generally considered a good thing, but this may break downstream builds. I've updated llvm, clang, lld, lldb and mlir deps, and included a list of the modification in the second part of the commit. 4. Replacing header inclusion by forward declaration. This has the same impact as 3.
Notable changes:
- llvm/Support/TargetParser.h no longer includes llvm/Support/AArch64TargetParser.h nor llvm/Support/ARMTargetParser.h - llvm/Support/TypeSize.h no longer includes llvm/Support/WithColor.h - llvm/Support/YAMLTraits.h no longer includes llvm/Support/Regex.h - llvm/ADT/SmallVector.h no longer includes llvm/Support/MemAlloc.h nor llvm/Support/ErrorHandling.h
You may need to add some of these headers in your compilation units, if needs be.
As an hint to the impact of the cleanup, running
clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Support/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
before: 8000919 lines after: 7917500 lines
Reduced dependencies also helps incremental rebuilds and is more ccache friendly, something not shown by the above metric :-)
Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup/5831
show more ...
|
Revision tags: llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
#
5c8462b5 |
| 07-Apr-2021 |
Abhina Sreeskantharajan <Abhina.Sreeskantharajan@ibm.com> |
[Windows] Remove global OF_None flag for Windows in ToolOutputFiles
Since we have created a new OF_TextWithCRLF flag, we no longer need to worry about OF_Text flag turning on CRLF translation. I can
[Windows] Remove global OF_None flag for Windows in ToolOutputFiles
Since we have created a new OF_TextWithCRLF flag, we no longer need to worry about OF_Text flag turning on CRLF translation. I can remove this workaround I added to globally open all ToolOutputFiles as binary on Windows.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D100034
show more ...
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4 |
|
#
4f750f6e |
| 19-Mar-2021 |
Abhina Sreeskantharajan <Abhina.Sreeskantharajan@ibm.com> |
[SystemZ][z/OS] Distinguish between text and binary files on z/OS
This patch consists of the initial changes to help distinguish between text and binary content correctly on z/OS. I would like to ge
[SystemZ][z/OS] Distinguish between text and binary files on z/OS
This patch consists of the initial changes to help distinguish between text and binary content correctly on z/OS. I would like to get feedback from Windows users on setting OF_None for all ToolOutputFiles. This seems to have been done as an optimization to prevent CRLF translation on Windows in the past.
Reviewed By: zibi
Differential Revision: https://reviews.llvm.org/D97785
show more ...
|
Revision tags: llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2 |
|
#
48cd9d9d |
| 03-Jun-2020 |
Pavel Labath <pavel@labath.sk> |
[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
[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
show more ...
|
Revision tags: llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1 |
|
#
adcd0268 |
| 28-Jan-2020 |
Benjamin Kramer <benny.kra@googlemail.com> |
Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here.
This is mostly m
Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
show more ...
|
Revision tags: llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
#
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1 |
|
#
3fc649cb |
| 23-Sep-2017 |
Reid Kleckner <rnk@google.com> |
[Support] Rename tool_output_file to ToolOutputFile, NFC
This class isn't similar to anything from the STL, so it shouldn't use the STL naming conventions.
llvm-svn: 314050
|
Revision tags: llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1, llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1, llvmorg-3.8.1, llvmorg-3.8.1-rc1, llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1, llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1, llvmorg-3.7.0, llvmorg-3.7.0-rc4, llvmorg-3.7.0-rc3, studio-1.4, llvmorg-3.7.0-rc2, llvmorg-3.7.0-rc1, llvmorg-3.6.2, llvmorg-3.6.2-rc1, llvmorg-3.6.1, llvmorg-3.6.1-rc1, llvmorg-3.5.2, llvmorg-3.5.2-rc1, llvmorg-3.6.0, llvmorg-3.6.0-rc4, llvmorg-3.6.0-rc3, llvmorg-3.6.0-rc2, llvmorg-3.6.0-rc1, llvmorg-3.5.1, llvmorg-3.5.1-rc2, llvmorg-3.5.1-rc1, llvmorg-3.5.0, llvmorg-3.5.0-rc4 |
|
#
3fd1e993 |
| 25-Aug-2014 |
Rafael Espindola <rafael.espindola@gmail.com> |
Modernize raw_fd_ostream's constructor a bit.
Take a StringRef instead of a "const char *". Take a "std::error_code &" instead of a "std::string &" for error.
A create static method would be even b
Modernize raw_fd_ostream's constructor a bit.
Take a StringRef instead of a "const char *". Take a "std::error_code &" instead of a "std::string &" for error.
A create static method would be even better, but this patch is already a bit too big.
llvm-svn: 216393
show more ...
|
Revision tags: llvmorg-3.5.0-rc3, llvmorg-3.5.0-rc2, llvmorg-3.5.0-rc1, llvmorg-3.4.2, llvmorg-3.4.2-rc1, llvmorg-3.4.1, llvmorg-3.4.1-rc2, llvmorg-3.4.1-rc1 |
|
#
81e7fd01 |
| 10-Jan-2014 |
Rafael Espindola <rafael.espindola@gmail.com> |
Use the simpler version of sys::fs::remove when possible.
llvm-svn: 198958
|
Revision tags: llvmorg-3.4.0, llvmorg-3.4.0-rc3, llvmorg-3.4.0-rc2, llvmorg-3.4.0-rc1 |
|
#
6d35481c |
| 16-Jul-2013 |
Rafael Espindola <rafael.espindola@gmail.com> |
Add a wrapper for open.
This centralizes the handling of O_BINARY and opens the way for hiding more differences (like how open behaves with directories).
llvm-svn: 186447
|
Revision tags: llvmorg-3.3.1-rc1 |
|
#
702a80c7 |
| 17-Jun-2013 |
Rafael Espindola <rafael.espindola@gmail.com> |
Reapply r183985 now that the missing check was added to PathV2.
llvm-svn: 184120
|
#
7648aa35 |
| 17-Jun-2013 |
Rafael Espindola <rafael.espindola@gmail.com> |
Revert "Remove a use of PathV1.h."
This reverts commit r183985.
We were missing the checks for not deleting things like /dev/null.
llvm-svn: 184111
|
#
40c908bf |
| 17-Jun-2013 |
Rafael Espindola <rafael.espindola@gmail.com> |
Don't use PathV1.h in LTOCodeGenerator.cpp
This patch also adds a simpler version of sys::fs::remove and a tool_output_file constructor for when we already have an open file.
llvm-svn: 184095
|
#
ca635dc9 |
| 14-Jun-2013 |
Rafael Espindola <rafael.espindola@gmail.com> |
Remove a use of PathV1.h.
llvm-svn: 183985
|
#
4f35da77 |
| 13-Jun-2013 |
Rafael Espindola <rafael.espindola@gmail.com> |
Don't use PathV1.h in Signals.h.
llvm-svn: 183947
|
Revision tags: llvmorg-3.3.0, llvmorg-3.3.0-rc3, llvmorg-3.3.0-rc2, llvmorg-3.3.0-rc1, llvmorg-3.2.0, llvmorg-3.2.0-rc3, llvmorg-3.2.0-rc2, llvmorg-3.2.0-rc1, llvmorg-3.1.0, llvmorg-3.1.0-rc3, llvmorg-3.1.0-rc2, llvmorg-3.1.0-rc1, llvmorg-3.0.0, llvmorg-3.0.0-rc4, llvmorg-3.0.0-rc3, llvmorg-3.0.0-rc2, llvmorg-3.0.0-rc1, llvmorg-2.9.0, llvmorg-2.9.0-rc3, llvmorg-2.9.0-rc2, llvmorg-2.9.0-rc1 |
|
#
447762da |
| 29-Nov-2010 |
Michael J. Spencer <bigcheesegs@gmail.com> |
Merge System into Support.
llvm-svn: 120298
|
#
0df7ea4c |
| 07-Oct-2010 |
Dan Gohman <gohman@apple.com> |
Move tool_output_file into its own file.
llvm-svn: 115973
|