summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Fix modules build with different technique to suppress Knuth debuggingTim Northover2018-08-061-37/+33
| | | | | | | | | | Currently we use #pragma push_macro(LLVM_DEBUG) to fiddle with the LLVM_DEBUG macro so that we can silence debugging the Knuth division algorithm unless it's actually desired. Unfortunately this is incompatible with enabling modules while building LLVM (via LLVM_ENABLE_MODULES=ON), probably due to a bug being fixed by D33004. llvm-svn: 339009
* Fix buildbot breakage.Rui Ueyama2018-08-041-2/+1
| | | | llvm-svn: 338940
* Use the same constants as zlib to represent compression level.Rui Ueyama2018-08-041-17/+4
| | | | | | | | | | This change allows users pass compression level that was not listed in the enum. Also, I think using different values than zlib's compression levels was just confusing. Differential Revision: https://reviews.llvm.org/D50196 llvm-svn: 338939
* [Support] Don't initialize compressed buffer allocated by zlib::compressFangrui Song2018-08-031-2/+2
| | | | | | | | | | | resize() (zeroing) makes every allocated page resident. The actual size of the compressed buffer is usually much smaller. Making every page resident is wasteful. When linking a test binary with ~1.9GiB uncompressed debug info with LLD, this optimization decreases max RSS by ~1.5GiB. Differential Revision: https://reviews.llvm.org/50223 llvm-svn: 338913
* [Windows FS] Allow moving files in TempFile::keepJeremy Morse2018-08-032-2/+10
| | | | | | | | | | | | In r338216 / D49860 TempFile::keep was extended to allow keeping across filesystems. The aim on Windows was to have this happen in rename_internal using the existing system API. However, to fix an issue and preserve the idea of "renaming" not being a move, put Windows keep-across-filesystem in TempFile::keep. Differential Revision: https://reviews.llvm.org/D50048 llvm-svn: 338841
* [Support] Add an enable bit to our DebugCountersGeorge Burgess IV2018-08-021-0/+2
| | | | | | | | | | | | | | | | | r337748 made us start incrementing DebugCounters all of the time. This makes tsan unhappy in multithreaded environments. Since it doesn't make much sense to use DebugCounters with multiple threads, this patch makes us only count anything if the user passed a -debug-counter option or if some other piece of code explicitly asks for it (e.g. the pass in D50031). The amount of global state here makes writing a unittest for this behavior somewhat awkward. So, no test is provided. Differential Revision: https://reviews.llvm.org/D50150 llvm-svn: 338762
* Unbreak build after r338758: specify lambda return type explicitlyKrzysztof Parzyszek2018-08-021-1/+1
| | | | llvm-svn: 338760
* [SCEV] Properly solve quadratic equationsKrzysztof Parzyszek2018-08-021-0/+191
| | | | | | Differential Revision: https://reviews.llvm.org/D48283 llvm-svn: 338758
* [Support] [NFC] change comment about retries in createUniqueEntityBob Haarman2018-08-021-2/+4
| | | | | | Rewording as requested on D50126 after the change was pushed. llvm-svn: 338755
* [Support] fix TempFile infinite loop and permission denied errorsBob Haarman2018-08-021-35/+42
| | | | | | | | | | | | | | | | | | | | Summary: On Windows, TempFile::create() was prone to failing with permission denied errors when a process created many tempfiles without providing a model large enough to accommodate them. There was also a problem with createUniqueEntity getting into an infinite loop when all names permitted by the model are in use. This change fixes both of these problems and adds a unit test for them. Reviewers: pcc, rnk, zturner Reviewed By: zturner Subscribers: inglorion, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D50126 llvm-svn: 338745
* Make ICF log output order deterministic.Rui Ueyama2018-07-311-0/+4
| | | | | | | | | | This patch does the same thing as r338153 for COFF. Note that this patch affects only the order of log messages. The output file is already deterministic. Differential Revision: https://reviews.llvm.org/D50023 llvm-svn: 338406
* Remove trailing spaceFangrui Song2018-07-3016-74/+74
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338293
* [dsymutil] Simplify temporary file handling.Jonas Devlieghere2018-07-292-4/+8
| | | | | | | | | | | Dsymutil's update functionality was broken on Windows because we tried to rename a file while we're holding open handles to that file. TempFile provides a solution for this through its keep(Twine) method. This patch changes dsymutil to make use of that functionality. Differential revision: https://reviews.llvm.org/D49860 llvm-svn: 338216
* [Support] Remove unnecessary MemoryBuffer::anchor (where the destructor ↵Fangrui Song2018-07-271-2/+1
| | | | | | serves as the key function) llvm-svn: 338175
* [Support] Use unsigned char for xxHash 64-bitFangrui Song2018-07-271-3/+3
| | | | | | Before, the last 3 bytes were char-signedness dependent. llvm-svn: 338128
* Revert r338027 to pacify build botJames Henderson2018-07-261-4/+4
| | | | llvm-svn: 338035
* [ADT] Replace std::isprint by llvm::isPrint.Michael Kruse2018-07-263-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [AArch64] Armv8.2-A: add the crypto extensionsSjoerd Meijer2018-07-261-0/+11
| | | | | | | | | This adds MC support for the crypto instructions that were made optional extensions in Armv8.2-A (AArch64 only). Differential Revision: https://reviews.llvm.org/D49370 llvm-svn: 338010
* [Support] Introduce createStringError helper functionVictor Leschuk2018-07-261-0/+4
| | | | | | | | | | | The function in question is copy-pasted lots of times in DWARF-related classes. Thus it will make sense to place its implementation into the Support library. Reviewed by: lhames Differential Revision: https://reviews.llvm.org/D49824 llvm-svn: 337995
* ADT: Shrink SmallVector size 0 to 16B on 64-bit platformsDuncan P. N. Exon Smith2018-07-241-2/+21
| | | | | | | | | | | | | | | | | | | | | SmallVectorTemplateCommon wants to know the address of the first element so it can detect whether it's in "small size" mode. The old implementation split the small array, creating the storage for the first element in SmallVectorTemplateCommon, and pulling the rest into SmallVectorStorage where we know the size of the array. This bloats SmallVector size 0 by the larger of sizeof(void*) and sizeof(T), and we're not even using the storage. The new implementation leaves the full small storage to SmallVectorStorage. To calculate the offset of the first element in SmallVectorTemplateCommon, we just need to know how far to jump, which we can calculate out-of-band. One subtlety is that we need SmallVectorStorage to be properly aligned even when the size is 0, to be sure that (for large alignments) we actually have the padding and it's well defined to do the pointer math. llvm-svn: 337820
* [DebugCounters] Keep track of total countsGeorge Burgess IV2018-07-231-10/+9
| | | | | | | | | | | | | | This patch makes debug counters keep track of the total number of times we've called `shouldExecute` for each counter, so it's easier to build automated tooling on top of these. A patch to print these counts is coming soon. Patch by Zhizhou Yang! Differential Revision: https://reviews.llvm.org/D49560 llvm-svn: 337748
* [Support] Add a UniqueStringSaver: like StringSaver, but deduplicating.Sam McCall2018-07-231-0/+7
| | | | | | | | | | | | Summary: Clarify contract of StringSaver (it null-terminates, callers rely on it). Reviewers: hokein Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49596 llvm-svn: 337677
* Reapply "ADT: Shrink size of SmallVector by 8B on 64-bit platforms"Duncan P. N. Exon Smith2018-07-201-11/+14
| | | | | | | | | | | | | | | | | | | | | | I'm optimistically reverting commit r337511, effectively reapplying r337504 *without* changes. The failing bots that had `SmallVector` in the backtrace recovered after the unrelated commit r337508. The backtraces looked bogus anyway, with `SmallVector::size()` calling (e.g.) `ConstantArray::get()`. Here's the original commit message: ADT: Shrink size of SmallVector by 8B on 64-bit platforms Represent size and capacity directly as unsigned and calculate `end()` using `begin() + size()`. This limits the maximum size/capacity of a vector to UINT32_MAX. https://reviews.llvm.org/D48518 llvm-svn: 337514
* Revert "ADT: Shrink size of SmallVector by 8B on 64-bit platforms"Duncan P. N. Exon Smith2018-07-201-14/+11
| | | | | | | | | | | | | | | | | | This reverts commit r337504 while I investigate a TSan bot failure that seems related: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/26526 #8 0x000055581f2895d8 (/b/sanitizer-x86_64-linux-autoconf/build/tsan_debug_build/bin/clang-7+0x1eb45d8) #9 0x000055581f294323 llvm::ConstantAggrKeyType<llvm::ConstantArray>::create(llvm::ArrayType*) const /b/sanitizer-x86_64-linux-autoconf/build/llvm/lib/IR/ConstantsContext.h:409:0 #10 0x000055581f294323 llvm::ConstantUniqueMap<llvm::ConstantArray>::create(llvm::ArrayType*, llvm::ConstantAggrKeyType<llvm::ConstantArray>, std::pair<unsigned int, std::pair<llvm::ArrayType*, llvm::ConstantAggrKeyType<llvm::ConstantArray> > >&) /b/sanitizer-x86_64-linux-autoconf/build/llvm/lib/IR/ConstantsContext.h:635:0 #11 0x000055581f294323 llvm::ConstantUniqueMap<llvm::ConstantArray>::getOrCreate(llvm::ArrayType*, llvm::ConstantAggrKeyType<llvm::ConstantArray>) /b/sanitizer-x86_64-linux-autoconf/build/llvm/lib/IR/ConstantsContext.h:654:0 #12 0x000055581f2944cb llvm::ConstantArray::get(llvm::ArrayType*, llvm::ArrayRef<llvm::Constant*>) /b/sanitizer-x86_64-linux-autoconf/build/llvm/lib/IR/Constants.cpp:964:0 #13 0x000055581fa27e19 llvm::SmallVectorBase::size() const /b/sanitizer-x86_64-linux-autoconf/build/llvm/include/llvm/ADT/SmallVector.h:53:0 #14 0x000055581fa27e19 llvm::SmallVectorImpl<llvm::Constant*>::resize(unsigned long) /b/sanitizer-x86_64-linux-autoconf/build/llvm/include/llvm/ADT/SmallVector.h:347:0 #15 0x000055581fa27e19 (anonymous namespace)::EmitArrayConstant(clang::CodeGen::CodeGenModule&, clang::ConstantArrayType const*, llvm::Type*, unsigned int, llvm::SmallVectorImpl<llvm::Constant*>&, llvm::Constant*) /b/sanitizer-x86_64-linux-autoconf/build/llvm/tools/clang/lib/CodeGen/CGExprConstant.cpp:669:0 llvm-svn: 337511
* ADT: Shrink size of SmallVector by 8B on 64-bit platformsDuncan P. N. Exon Smith2018-07-191-11/+14
| | | | | | | | | | | Representing size and capacity directly as unsigned and calculate `end()` using `begin() + size()`. This limits the maximum size/capacity of a vector to UINT32_MAX. https://reviews.llvm.org/D48518 llvm-svn: 337504
* [APInt] Keep the original bit width in quotient and remainderKrzysztof Parzyszek2018-07-191-16/+17
| | | | | | | | | | | Some trivial cases in udivrem were handled by directly assigning 0 or 1 to APInt objects. This would set the bit width to 1, instead of the bit width of the inputs. A potentially undesirable side effect of that is that with the bit width of 1, 1 equals -1. Differential Revision: https://reviews.llvm.org/D49554 llvm-svn: 337478
* [Support] Build fix for Haiku when checking for a local filesystemTim Northover2018-07-181-0/+3
| | | | | | | | | Haiku does not expose information about local versus remote mounts, so just return false, like Cygwin. Patch by Niels Sascha Reedijk. llvm-svn: 337389
* Don't assert that a size_t fits into 64bit.Joerg Sonnenberger2018-07-171-1/+0
| | | | | | Avoids tautological compare warnings on 32bit platforms. llvm-svn: 337269
* [Support] Harded JSON against invalid UTF-8.Sam McCall2018-07-101-4/+45
| | | | | | | | | Parsing invalid UTF-8 input is now a parse error. Creating JSON values from invalid UTF-8 now triggers an assertion, and (in no-assert builds) substitutes the unicode replacement character. Strings retrieved from json::Value are always valid UTF-8. llvm-svn: 336657
* [Support] Make JSON handle doubles and int64s losslesslySam McCall2018-07-091-16/+26
| | | | | | | | | | | | | | | | | | | Summary: This patch adds a new "integer" ValueType, and renames Number -> Double. This allows us to preserve the full precision of int64_t when parsing integers from the wire, or constructing from an integer. The API is unchanged, other than giving asInteger() a clearer contract. In addition, always output doubles with enough precision that parsing will reconstruct the same double. Reviewers: simon_tatham Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D46209 llvm-svn: 336541
* Lift JSON library from clang-tools-extra/clangd to llvm/Support.Sam McCall2018-07-092-0/+643
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This consists of four main parts: - an type json::Expr representing JSON values of dynamic kind, which can be composed, inspected, and modified - a JSON parser from string -> json::Expr - a JSON printer from json::Expr -> string, with optional pretty-printing - a convention for mapping json::Expr <=> native types (fromJSON/toJSON) Mapping functions are provided for primitives (e.g. int, vector) and the ObjectMapper helper helps implement fromJSON for struct/object types. Based on clangd's usage, a couple of places I'd appreciate review attention: - fromJSON returns only bool. A richer error-signaling mechanism may be useful to provide useful messages, or let recursive fromJSONs (containers/structs) do careful error recovery. - should json::obj be always explicitly written (like json::ary) - there's no streaming parse API. I suspect there are some simple wins like a callback API where the document is a long array, and each element is small. But this can probably be bolted on easily when we see the need. Reviewers: bkramer, labath Subscribers: mgorny, ilya-biryukov, ioeric, MaskRay, llvm-commits Differential Revision: https://reviews.llvm.org/D45753 llvm-svn: 336534
* [OpenEmbedded] Add OpenEmbedded vendorMandeep Singh Grang2018-07-051-0/+2
| | | | | | | | | | | | | | | | | | Summary: The lib paths are not correctly picked up for OpenEmbedded sysroots (like arm-oe-linux-gnueabi). I fix this in a follow-up clang patch. But in order to add the correct libs I need to detect if the vendor is oe. For this reason, it is first necessary to teach llvm to detect oe vendor, which is what this patch does. Reviewers: chandlerc, compnerd, rengolin, javed.absar Reviewed By: compnerd Subscribers: kristof.beyls, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D48861 llvm-svn: 336401
* [ThinLTO] Update ThinLTO cache file atimes when on WindowsAndrew Ng2018-07-041-0/+15
| | | | | | | | | | | | | | | | | | ThinLTO cache file access times are used for expiration based pruning and since Vista, file access times are not updated by Windows by default: https://blogs.technet.microsoft.com/filecab/2006/11/07/disabling-last-access-time-in-windows-vista-to-improve-ntfs-performance This means on Windows, cache files are currently being pruned from creation time. This change manually updates cache files that are accessed by ThinLTO, when on Windows. Patch by Owen Reynolds. Differential Revision: https://reviews.llvm.org/D47266 llvm-svn: 336276
* Fix typo in lib/Support/Path.cpp to test commit accessVladimir Stefanovic2018-07-031-1/+1
| | | | llvm-svn: 336216
* [ARM][AArch64] Armv8.4-A EnablementSjoerd Meijer2018-06-292-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Initial patch adding assembly support for Armv8.4-A. Besides adding v8.4 as a supported architecture to the usual places, this also adds target features for the different crypto algorithms. Armv8.4-A introduced new crypto algorithms, made them optional, and allows different combinations: - none of the v8.4 crypto functions are supported, which is independent of the implementation of the Armv8.0 SHA1 and SHA2 instructions. - the v8.4 SHA512 and SHA3 support is implemented, in this case the Armv8.0 SHA1 and SHA2 instructions must also be implemented. - the v8.4 SM3 and SM4 support is implemented, which is independent of the implementation of the Armv8.0 SHA1 and SHA2 instructions. - all of the v8.4 crypto functions are supported, in this case the Armv8.0 SHA1 and SHA2 instructions must also be implemented. The v8.4 crypto instructions are added to AArch64 only, and not AArch32, and are made optional extensions to Armv8.2-A. The user-facing Clang options will map on these new target features, their naming will be compatible with GCC and added in follow-up patches. The Armv8.4-A instruction sets can be downloaded here: https://developer.arm.com/products/architecture/a-profile/exploration-tools Differential Revision: https://reviews.llvm.org/D48625 llvm-svn: 335953
* Add a flag to FileOutputBuffer that allows modification.Zachary Turner2018-06-282-23/+57
| | | | | | | | | | | | | FileOutputBuffer creates a temp file and on commit atomically renames the temp file to the destination file. Sometimes we want to modify an existing file in place, but still have the atomicity guarantee. To do this we can initialize the contents of the temp file from the destination file (if it exists), that way the resulting FileOutputBuffer can have only selective bytes modified. Committing will then atomically replace the destination file as desired. llvm-svn: 335902
* Fix MSVC "not all control paths return a value" warnings. NFCI.Simon Pilgrim2018-06-261-0/+2
| | | | llvm-svn: 335584
* [APInt] Add helpers for rounding u/sdivs.Tim Shen2018-06-251-0/+46
| | | | | | | | | | Reviewers: sanjoy, craig.topper Subscribers: jlebar, hiraditya, bixia, llvm-commits Differential Revision: https://reviews.llvm.org/D48498 llvm-svn: 335557
* Add OpenBSD support to the Threading codeBrad Smith2018-06-231-3/+5
| | | | llvm-svn: 335426
* ADT: Use EBO to shrink SmallVector size 1Duncan P. N. Exon Smith2018-06-231-0/+4
| | | | | | | SmallVectorStorage is empty when its size is 1; use inheritance so that the empty base class optimization kicks in. llvm-svn: 335421
* Fix namespaces. No functionality change.Benjamin Kramer2018-06-161-0/+2
| | | | llvm-svn: 334890
* Avoid copying PrettyStackTrace messages an extra time on Apple OSsJordan Rose2018-06-151-2/+2
| | | | | | | | We were unnecessarily going from SmallString to std::string just to get a null-terminated C string. So just...don't do that. Crash slightly faster! llvm-svn: 334841
* Revert "Enable ThreadPool to queue tasks that return values."Zachary Turner2018-06-131-2/+19
| | | | | | | | This is failing to compile when LLVM_ENABLE_THREADS is false, and the fix is not immediately obvious, so reverting while I look into it. llvm-svn: 334658
* Enable ThreadPool to support tasks that return values.Zachary Turner2018-06-131-19/+2
| | | | | | | | | | | | | | | | | | | | | Previously ThreadPool could only queue async "jobs", i.e. work that was done for its side effects and not for its result. It's useful occasionally to queue async work that returns a value. From an API perspective, this is very intuitive. The previous API just returned a shared_future<void>, so all we need to do is make it return a shared_future<T>, where T is the type of value that the operation returns. Making this work required a little magic, but ultimately it's not too bad. Instead of keeping a shared queue<packaged_task<void()>> we just keep a shared queue<unique_ptr<TaskBase>>, where TaskBase is a class with a pure virtual execute() method, then have a templated derived class that stores a packaged_task<T()>. Everything else works out pretty cleanly. Differential Revision: https://reviews.llvm.org/D48115 llvm-svn: 334643
* LTO: Keep file handles open for memory mapped files.Peter Collingbourne2018-06-134-101/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Windows we've observed that if you open a file, write to it, map it into memory and close the file handle, the contents of the memory mapping can sometimes be incorrect. That was what we did when adding an entry to the ThinLTO cache using the TempFile and MemoryBuffer classes, and it was causing intermittent build failures on Chromium's ThinLTO bots on Windows. More details are in the associated Chromium bug (crbug.com/786127). We can prevent this from happening by keeping a handle to the file open while the mapping is active. So this patch changes the mapped_file_region class to duplicate the file handle when mapping the file and close it upon unmapping it. One gotcha is that the file handle that we keep open must not have been created with FILE_FLAG_DELETE_ON_CLOSE, as otherwise the operating system will prevent other processes from opening the file. We can achieve this by avoiding the use of FILE_FLAG_DELETE_ON_CLOSE altogether. Instead, we use SetFileInformationByHandle with FileDispositionInfo to manage the delete-on-close bit. This lets us remove the hack that we used to use to clear the delete-on-close bit on a file opened with FILE_FLAG_DELETE_ON_CLOSE. A downside of using SetFileInformationByHandle/FileDispositionInfo as opposed to FILE_FLAG_DELETE_ON_CLOSE is that it prevents us from using CreateFile to open the file while the flag is set, even within the same process. This doesn't seem to matter for almost every client of TempFile, except for LockFileManager, which calls sys::fs::create_link to create a hard link from the lock file, and in the process of doing so tries to open the file. To prevent this change from breaking LockFileManager I changed it to stop using TempFile by effectively reverting r318550. Differential Revision: https://reviews.llvm.org/D48051 llvm-svn: 334630
* Do not enforce absolute path argv0 in windowsHans Wennborg2018-06-131-29/+39
| | | | | | | | | | | | | | | | Even if we support no-canonical-prefix on clang-cl(https://reviews.llvm.org/D47480), argv0 becomes absolute path in clang-cl and that embeds absolute path in /showIncludes. This patch removes such full path normalization from InitLLVM on windows, and that removes absolute path from clang-cl output (obj/stdout/stderr) when debug flag is disabled. Patch by Takuto Ikuta! Differential Revision https://reviews.llvm.org/D47578 llvm-svn: 334602
* Refactor ExecuteAndWait to take StringRefs.Zachary Turner2018-06-125-73/+80
| | | | | | | | | | | | | | | | | | | This simplifies some code which had StringRefs to begin with, and makes other code more complicated which had const char* to begin with. In the end, I think this makes for a more idiomatic and platform agnostic API. Not all platforms launch process with null terminated c-string arrays for the environment pointer and argv, but the api was designed that way because it allowed easy pass-through for posix-based platforms. There's a little additional overhead now since on posix based platforms we'll be takign StringRefs which were constructed from null terminated strings and then copying them to null terminate them again, but from a readability and usability standpoint of the API user, I think this API signature is strictly better. llvm-svn: 334518
* Fix build errors on some configurationsPavel Labath2018-06-113-4/+4
| | | | | | | | | | | | It's been reported <http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180611/559616.html> that template argument deduction for RetryAfterSignal fails if open is not prefixed with "::". This should help us build correctly on those platforms and explicitly specifying the namespace is more correct anyway. llvm-svn: 334403
OpenPOWER on IntegriCloud