summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/raw_ostream.cpp
Commit message (Collapse)AuthorAgeFilesLines
* llvm-ar: Fix MinGW compilationHans Wennborg2020-02-281-1/+1
| | | | | | | | | | | | | | | | llvm-ar is using CompareStringOrdinal which is available only starting with Windows Vista (WINVER 0x600). Fix this by hoising WindowsSupport.h, which sets _WIN32_WINNT to 0x0601, up to llvm/include/llvm/Support and use it in llvm-ar. Patch by Cristian Adam! Differential revision: https://reviews.llvm.org/D74599 (cherry picked from commit 01f9abbb50b11dd26b9ccb7cb565cc955d2b9c74) This is for https://bugs.llvm.org/show_bug.cgi?id=44907
* raw_ostream - fix static analyzer warnings. NFCI.Simon Pilgrim2019-11-081-6/+6
| | | | | - uninitialized variables - make BufferKind a scoped enum class
* Revert "raw_ostream: add operator<< overload for std::error_code"Pavel Labath2019-08-141-5/+0
| | | | | | | | | | | This reverts commit r368849, because it breaks some bots (e.g. llvm-clang-x86_64-win-fast). It turns out this is not as NFC as we had hoped, because operator== will consider two std::error_codes to be distinct even though they both hold "success" values if they have different categories. llvm-svn: 368854
* raw_ostream: add operator<< overload for std::error_codePavel Labath2019-08-141-0/+5
| | | | | | | | | | | | | | | | | | | | | | | Summary: The main motivation for this is unit tests, which contain a large macro for pretty-printing std::error_code, and this macro is duplicated in every file that needs to do this. However, the functionality may be useful elsewhere too. In this patch I have reimplemented the existing ASSERT_NO_ERROR macros to reuse the new functionality, but I have kept the macro (as a one-liner) as it is slightly more readable than ASSERT_EQ(..., std::error_code()). Reviewers: sammccall, ilya-biryukov Subscribers: zturner, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65643 llvm-svn: 368849
* Re-submit r367649: Improve raw_ostream so that you can "write" colors using ↵Rui Ueyama2019-08-071-2/+31
| | | | | | | | | operator<< The original patch broke buildbots, perhaps because it changed the default setting whether colors are enabled or not. llvm-svn: 368131
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-051-1/+1
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* Revert r367649: Improve raw_ostream so that you can "write" colors using ↵Rui Ueyama2019-08-021-35/+6
| | | | | | | | operator<< This reverts commit r367649 in an attempt to unbreak Windows bots. llvm-svn: 367658
* Improve raw_ostream so that you can "write" colors using operator<<Rui Ueyama2019-08-021-6/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. raw_ostream supports ANSI colors so that you can write messages to the termina with colors. Previously, in order to change and reset color, you had to call `changeColor` and `resetColor` functions, respectively. So, if you print out "error: " in red, for example, you had to do something like this: OS.changeColor(raw_ostream::RED); OS << "error: "; OS.resetColor(); With this patch, you can write the same code as follows: OS << raw_ostream::RED << "error: " << raw_ostream::RESET; 2. Add a boolean flag to raw_ostream so that you can disable colored output. If you disable colors, changeColor, operator<<(Color), resetColor and other color-related functions have no effect. Most LLVM tools automatically prints out messages using colors, and you can disable it by passing a flag such as `--disable-colors`. This new flag makes it easy to write code that works that way. Differential Revision: https://reviews.llvm.org/D65564 llvm-svn: 367649
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | | This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} llvm-svn: 366177
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* Add vtable anchor to classes.Richard Trieu2018-12-291-0/+2
| | | | llvm-svn: 350142
* [Windows] Convert from UTF-8 to UTF-16 when writing to a Windows consoleReid Kleckner2018-09-051-8/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Calling WriteConsoleW is the most reliable way to print Unicode characters to a Windows console. If binary data gets printed to the console, attempting to re-encode it shouldn't be a problem, since garbage in can produce garbage out. This breaks printing strings in the local codepage, which WriteConsoleA knows how to handle. For example, this can happen when user source code is encoded with the local codepage, and an LLVM tool quotes it while emitting a caret diagnostic. This is unfortunate, but well-behaved tools should validate that their input is UTF-8 and escape non-UTF-8 characters before sending them to raw_fd_ostream. Clang already does this, but not all LLVM tools do this. One drawback to the current implementation is printing a string a byte at a time doesn't work. Consider this LLVM code: for (char C : MyStr) outs() << C; Because outs() is now unbuffered, we wil try to convert each byte to UTF-16, which will fail. However, this already didn't work, so I think we may as well update callers that do that as we find them to print complete portions of strings. You can see a real example of this in my patch to SourceMgr.cpp Fixes PR38669 and PR36267. Reviewers: zturner, efriedma Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D51558 llvm-svn: 341433
* Fix raw_fd_ostream::write_impl hang due to an infinite loop with large outputOwen Reynolds2018-08-061-4/+4
| | | | | | | | | | On windows when raw_fd_ostream::write_impl calls write, a 32 bit input is required for character count. As a variable with size_t is used for this argument, on x64 integral demotion occurs. In the case of large files an infinite loop follows. See: https://bugs.llvm.org/show_bug.cgi?id=37926 This fix allows the output of files larger than the previous int32 limit. Differential Revision: https://reviews.llvm.org/D48948 llvm-svn: 339027
* Revert r338027 to pacify build botJames Henderson2018-07-261-4/+4
| | | | llvm-svn: 338035
* [ADT] Replace std::isprint by llvm::isPrint.Michael Kruse2018-07-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The standard library functions ::isprint/std::isprint have platform- and locale-dependent behavior which makes LLVM's output less predictable. In particular, regression tests my fail depending on the implementation of these functions. Implement llvm::isPrint in StringExtras.h with a standard behavior and replace all uses of ::isprint/std::isprint by a call it llvm::isPrint. The function is inlined and does not look up language settings so it should perform better than the standard library's version. Such a replacement has already been done for isdigit, isalpha, isxdigit in r314883. gtest does the same in gtest-printers.cc using the following justification: // Returns true if c is a printable ASCII character. We test the // value of c directly instead of calling isprint(), which is buggy on // Windows Mobile. inline bool IsPrintableAscii(wchar_t c) { return 0x20 <= c && c <= 0x7E; } Similar issues have also been encountered by Julia: https://github.com/JuliaLang/julia/issues/7416 I noticed the problem myself when on Windows isprint('\t') started to evaluate to true (see https://stackoverflow.com/questions/51435249) and thus caused several unit tests to fail. The result of isprint doesn't seem to be well-defined even for ASCII characters. Therefore I suggest to replace isprint by a platform-independent version. Differential Revision: https://reviews.llvm.org/D49680 llvm-svn: 338034
* Fix raw_fd_ostream::write_impl hang with large outputJames Henderson2018-07-261-4/+4
| | | | | | | | | | | | | | | | | | | On Windows when raw_fd_ostream::write_impl calls write, a 32 bit input is required for character count. As a variable with size_t is used for this argument on x64 integral demotion occurs. In the case of large files an infinite loop follows. See PR37926. This fix allows the output of files larger than previous int32 limit. Differential Revision: https://reviews.llvm.org/D48948 Patch by Owen Reynolds Reviewed by: zturner llvm-svn: 338027
* [FileSystem] Split up the OpenFlags enumeration.Zachary Turner2018-06-071-3/+30
| | | | | | | | | | | | | | | | | This breaks the OpenFlags enumeration into two separate enumerations: OpenFlags and CreationDisposition. The first controls the behavior of the API depending on whether or not the target file already exists, and is not a flags-based enum. The second controls more flags-like values. This yields a more easy to understand API, while also allowing flags to be passed to the openForRead api, where most of the values didn't make sense before. This also makes the apis more testable as it becomes easy to enumerate all the configurations which make sense, so I've added many new tests to exercise all the different values. llvm-svn: 334221
* [Support] Remove unused raw_ostream::handle whose anchor role was superseded ↵Fangrui Song2018-06-021-3/+0
| | | | | | by anchor() llvm-svn: 333817
* Support: Add a raw_ostream::write_zeros() function. NFCI.Peter Collingbourne2018-05-171-14/+26
| | | | | | | | | | This will eventually replace MCObjectWriter::WriteZeros. Part of PR37466. Differential Revision: https://reviews.llvm.org/D47033 llvm-svn: 332675
* s/LLVM_ON_WIN32/_WIN32/, llvmNico Weber2018-04-291-4/+4
| | | | | | | | | | | | | | LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of a reinvented one. See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. No intended behavior change. This moves over all uses of the macro, but doesn't remove the definition of it in (llvm-)config.h yet. llvm-svn: 331127
* Add missing vtable anchorsWeiming Zhao2018-04-111-0/+6
| | | | | | | | | | | | | | Summary: This patch adds anchor() for MemoryBuffer, raw_fd_ostream, RTDyldMemoryManager, SectionMemoryManager, etc. Reviewers: jlebar, eli.friedman, dblaikie Reviewed By: dblaikie Subscribers: mehdi_amini, mgorny, dblaikie, weimingz, llvm-commits Differential Revision: https://reviews.llvm.org/D45244 llvm-svn: 329861
* Remove HAVE_WRITEV that's unused after r255837.Nico Weber2018-04-021-3/+0
| | | | llvm-svn: 328977
* [Support] Make the default chunk size of raw_fd_ostream to 1 GiB.Rui Ueyama2017-10-311-11/+12
| | | | | | | | | | | | | | | | | | Previously, we call write(2) for each 32767 byte chunk. That is not efficient because Linux can handle much larger write requests. This patch changes the chunk size on Linux to 1 GiB. This patch also changes the default chunks size to SSIZE_MAX. I think that doesn't in practice change this function's behavior on any operating system because SSIZE_MAX on 64-bit machine is unrealistically large, and writing 2 GiB (SSIZE_MAX on 32-bit) on a 32-bit machine by a single call of write(2) is also unrealistic, as the userspace is usually limited to 2 GiB. That said, it is in general a good thing to do because a write larger than SSIZE_MAX is implementation-defined in POSIX. Differential Revision: https://reviews.llvm.org/D39444 llvm-svn: 317015
* [raw_fd_ostream] report actual error in error messagesBob Haarman2017-10-241-9/+11
| | | | | | | | | | | | | | | | | Summary: Previously, we would emit error messages like "IO failure on output stream". This change causes use to include information about what actually went wrong, e.g. "No space left on device". Reviewers: sunfish, rnk Reviewed By: rnk Subscribers: mehdi_amini, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D39203 llvm-svn: 316404
* llvm-dwarfdump: support dumping UUIDs of Mach-O binaries.Adrian Prantl2017-09-131-0/+10
| | | | | | | This is a feature supported by Darwin dwarfdump. UUIDs are used to associate executables with their .dSYM bundles. llvm-svn: 313165
* [Support] Update comments about stdout, raw_fd_ostream, and outs()Reid Kleckner2017-08-041-9/+8
| | | | | | | | | | | | | | | The full story is in the comments: // Do not attempt to close stdout or stderr. We used to try to maintain the // property that tools that support writing file to stdout should not also // write informational output to stdout, but in practice we were never able to // maintain this invariant. Many features have been added to LLVM and clang // (-fdump-record-layouts, optimization remarks, etc) that print to stdout, so // users must simply be aware that mixed output and remarks is a possibility. NFC, I am just updating comments to reflect reality. llvm-svn: 310016
* Support: Add llvm::center_justify.Frederich Munch2017-07-131-6/+23
| | | | | | | | | | | | | | Summary: Completes the set. Reviewers: ruiu Reviewed By: ruiu Subscribers: ruiu, llvm-commits Differential Revision: https://reviews.llvm.org/D35278 llvm-svn: 307922
* Support: chunk writing on LinuxSaleem Abdulrasool2017-06-201-0/+4
| | | | | | | | This is a workaround for large file writes. It has been witnessed that write(2) failing with EINVAL (22) due to a large value (>2G). Thanks to James Knight for the help with coming up with a sane test case. llvm-svn: 305846
* Update comment for r299098 per feedback from James Henderson.Yaron Keren2017-03-311-2/+1
| | | | llvm-svn: 299207
* Following r297661, disable dup workaround to disable duplicate STDOUT fd ↵Yaron Keren2017-03-301-1/+8
| | | | | | | | | | | | | | | | closing and instead directly prevent closing of STD* file descriptors. We do not want to close STDOUT as there may have been several uses of it such as the case: llc %s -o=- -pass-remarks-output=- -filetype=asm which cause multiple closes of STDOUT_FILENO and/or use-after-close of it. Using dup() in getFD doesn't work as we end up with original STDOUT_FILENO open anyhow. reviewed by Rafael Espindola Differential Revision: https://reviews.llvm.org/D31505 llvm-svn: 299098
* Bring back r297624.Rafael Espindola2017-03-131-1/+1
| | | | | | The issues was just a missing REQUIRES in the test. llvm-svn: 297661
* Revert "Fix crash when multiple raw_fd_ostreams to stdout are created."Rafael Espindola2017-03-131-1/+1
| | | | | | | This reverts commit r297624. It was failing on the bots. llvm-svn: 297657
* Fix crash when multiple raw_fd_ostreams to stdout are created.Rafael Espindola2017-03-131-1/+1
| | | | | | | | | | | | | | | | | | | | | If raw_fd_ostream is constructed with the path of "-", it claims ownership of the stdout file descriptor. This means that it closes stdout when it is destroyed. If there are multiple users of raw_fd_ostream wrapped around stdout, then a crash can occur because of operations on a closed stream. An example of this would be running something like "clang -S -o - -MD -MF - test.cpp". Alternatively, using outs() (which creates a local version of raw_fd_stream to stdout) anywhere combined with such a stream usage would cause the crash. The fix duplicates the stdout file descriptor when used within raw_fd_ostream, so that only that particular descriptor is closed when the stream is destroyed. Patch by James Henderson! llvm-svn: 297624
* Re-commit r289184, "Support: Use a 64-bit seek in raw_fd_ostream::seek()." ↵Peter Collingbourne2016-12-091-0/+6
| | | | | | with a configure-time check for lseek64. llvm-svn: 289187
* Revert r289184, we need more configury for Darwin and *BSD.Peter Collingbourne2016-12-091-5/+1
| | | | llvm-svn: 289185
* Support: Use a 64-bit seek in raw_fd_ostream::seek().Peter Collingbourne2016-12-091-1/+5
| | | | llvm-svn: 289184
* [Support] Introduce llvm::formatv() function.Zachary Turner2016-11-111-5/+12
| | | | | | | | | | | | | | | | | | This introduces a new type-safe general purpose formatting library. It provides compile-time type safety, does not require a format specifier (since the type is deduced), and provides mechanisms for extending the format capability to user defined types, and overriding the formatting behavior for existing types. This patch additionally adds documentation for the API to the LLVM programmer's manual. Mailing List Thread: http://lists.llvm.org/pipermail/llvm-dev/2016-October/105836.html Differential Revision: https://reviews.llvm.org/D25587 llvm-svn: 286682
* Fix type ambiguity with std::maxZachary Turner2016-11-101-1/+1
| | | | llvm-svn: 286498
* [Support] Improve flexibility of binary blob formatter.Zachary Turner2016-11-101-33/+50
| | | | | | | | | | | This makes it possible to indent a binary blob by a certain number of bytes, and also makes some things more idiomatic. Finally, it integrates this binary blob formatter into ScopedPrinter which used to have its own implementation of this algorithm. Differential Revision: https://reviews.llvm.org/D26477 llvm-svn: 286495
* Added the ability to dump hex bytes easily into a raw_ostream.Greg Clayton2016-11-091-0/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unit tests were added to verify this functionality keeps working correctly. Example output for raw hex bytes: llvm::ArrayRef<uint8_t> Bytes = ...; llvm::outs() << format_hex_bytes(Bytes); 554889e5 4881ec70 04000048 8d051002 00004c8d 05fd0100 004c8b0d d0020000 Example output for raw hex bytes with offsets: llvm::outs() << format_hex_bytes(Bytes, 0x100000d10); 0x0000000100000d10: 554889e5 4881ec70 04000048 8d051002 0x0000000100000d20: 00004c8d 05fd0100 004c8b0d d0020000 Example output for raw hex bytes with ASCII with offsets: llvm::outs() << format_hex_bytes_with_ascii(Bytes, 0x100000d10); 0x0000000100000d10: 554889e5 4881ec70 04000048 8d051002 |UH.?H.?p...H....| 0x0000000100000d20: 00004c8d 05fd0100 004c8b0d d0020000 |..L..?...L..?...| The default groups bytes into 4 byte groups, but this can be changed to 1 byte: llvm::outs() << format_hex_bytes(Bytes, 0x100000d10, 16 /*NumPerLine*/, 1 /*ByteGroupSize*/); 0x0000000100000d10: 55 48 89 e5 48 81 ec 70 04 00 00 48 8d 05 10 02 0x0000000100000d20: 00 00 4c 8d 05 fd 01 00 00 4c 8b 0d d0 02 00 00 llvm::outs() << format_hex_bytes(Bytes, 0x100000d10, 16 /*NumPerLine*/, 2 /*ByteGroupSize*/); 0x0000000100000d10: 5548 89e5 4881 ec70 0400 0048 8d05 1002 0x0000000100000d20: 0000 4c8d 05fd 0100 004c 8b0d d002 0000 llvm::outs() << format_hex_bytes(Bytes, 0x100000d10, 8 /*NumPerLine*/, 1 /*ByteGroupSize*/); 0x0000000100000d10: 55 48 89 e5 48 81 ec 70 0x0000000100000d18: 04 00 00 48 8d 05 10 02 0x0000000100000d20: 00 00 4c 8d 05 fd 01 00 0x0000000100000d28: 00 4c 8b 0d d0 02 00 00 https://reviews.llvm.org/D26405 llvm-svn: 286316
* Resubmit "Add support for advanced number formatting."Zachary Turner2016-10-291-9/+23
| | | | | | | | | | | | | This resubmits r284436 and r284437, which were reverted in r284462 as they were breaking the AArch64 buildbot. The breakage on AArch64 turned out to be a miscompile which is still not fixed, but is actively tracked at llvm.org/pr30748. This resubmission re-writes the code in a way so as to make the miscompile not happen. llvm-svn: 285483
* Revert "Resubmit "Add support for advanced number formatting.""Renato Golin2016-10-181-19/+9
| | | | | | | | | | This reverts commits 284436 and 284437 because they still break AArch64 bots: Value of: format_number(-10, IntegerStyle::Integer, 1) Actual: "-0" Expected: "-10" llvm-svn: 284462
* Rename HexStyle -> HexFormatStyle, and remove a constexpr.Zachary Turner2016-10-171-7/+7
| | | | | | This should fix the remaining broken builds. llvm-svn: 284437
* Resubmit "Add support for advanced number formatting."Zachary Turner2016-10-171-9/+19
| | | | | | | | | | This resubmits commits 284425 and r284428, which were reverted in r284429 due to some infinite recursion caused by an incorrect selection of function overloads. Reproduced the failure on Linux using GCC 4.8.4, and confirmed that with the new patch the tests path on GCC as well as MSVC. So hopefully this fixes everything. llvm-svn: 284436
* Revert formatting changes.Zachary Turner2016-10-171-19/+9
| | | | | | | This reverts r288425 and r284428 as they are causing test crashes on some systems. llvm-svn: 284429
* [Support] Add support for "advanced" number formatting.Zachary Turner2016-10-171-9/+19
| | | | | | | | | | | | | | | raw_ostream has not afforded a lot of flexibility in terms of how to format numbers when outputting. Wrap this all up into a set of low level helper functions that can be used to output numbers with arbitrary precision, alignment, format, etc and then update raw_ostream to use these functions. This will be useful for upcoming improvements to llvm's string formatting libraries, but are still useful independently. Differential Revision: https://reviews.llvm.org/D25497 llvm-svn: 284425
* [raw_ostream] Raise some helper functions out of raw_ostream.Zachary Turner2016-10-111-137/+19
| | | | | | | | | | Low level functionality to format numbers were embedded in the implementation of raw_ostream. I have need to use these through an interface other than the overloaded stream operators, so they need to be raised to a level that they can be used from either raw_ostream operators or other code. llvm-svn: 283921
* Fix some Clang-tidy modernize-use-using and Include What You Use warnings; ↵Eugene Zelenko2016-08-231-8/+5
| | | | | | | | other minor fixes. Differential revision: https://reviews.llvm.org/D23789 llvm-svn: 279535
* Replace a few more "fall through" comments with LLVM_FALLTHROUGHJustin Bogner2016-08-171-4/+4
| | | | | | Follow up to r278902. I had missed "fall through", with a space. llvm-svn: 278970
* C++11 is required, remove some preprocessor checks for itHal Finkel2016-03-281-1/+1
| | | | | | | We require C++11 to build, so remove a few remaining preprocessor checks for '__cplusplus >= 201103L'. This should always be true. llvm-svn: 264572
OpenPOWER on IntegriCloud