summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Windows
Commit message (Collapse)AuthorAgeFilesLines
...
* 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-121-14/+7
| | | | | | | | | | | | | | | | | | | 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
* Attempt 3: Resubmit "[Support] Expose flattenWindowsCommandLine."Zachary Turner2018-06-102-116/+73
| | | | | | | | | | | | | | | | | | I took some liberties and quoted fewer characters than before, based on an article from MSDN which says that only certain characters cause an arg to require quoting. This seems to be incorrect, though, and worse it seems to be a difference in Windows version. The bot that fails is Windows 7, and I can't reproduce the failure on Win 10. But it's definitely related to quoting and special characters, because both tests that fail have a * in the argument, which is one of the special characters that would cause an argument to be quoted before but not any longer after the new patch. Since I don't have Win 7, all I can do is just guess that I need to restore the old quoting rules. So this patch does that in hopes that it fixes the problem on Windows 7. llvm-svn: 334375
* Revert "Resubmit "[Support] Expose flattenWindowsCommandLine.""Zachary Turner2018-06-102-73/+116
| | | | | | | | | This reverts commit 65243b6d19143cb7a03f68df0169dcb63e8b4632. Seems like it's not a flake. It might have something to do with the '*' character being in a command line. llvm-svn: 334356
* Resubmit "[Support] Expose flattenWindowsCommandLine."Zachary Turner2018-06-102-116/+73
| | | | | | | | | There were a few linux compilation failures, but other than that I think this was just a flake that caused the tests to fail. I'm going to resubmit and see if the failures go away, if not I'll revert again. llvm-svn: 334355
* Revert "[Support] Expose flattenWindowsCommandLine."Zachary Turner2018-06-091-68/+114
| | | | | | | | | This reverts commit 10d2e88e87150a35dc367ba30716189d2af26774. This is causing some test failures for some reason, reverting while I investigate. llvm-svn: 334354
* [Support] Expose flattenWindowsCommandLine.Zachary Turner2018-06-091-114/+68
| | | | | | | | | | | This function was internal to Program.inc, but I've needed this on several occasions when I've had to use CreateProcess without llvm's sys::Execute functions. In doing so, I noticed that the function was written using unsafe C-string access and was pretty hard to understand / make sense of, so I've also re-written the functions to use more modern LLVM constructs. llvm-svn: 334353
* Clean up some code in Program.Zachary Turner2018-06-081-10/+10
| | | | | | | | | | NFC here, this just raises some platform specific ifdef hackery out of a class and creates proper platform-independent typedefs for the relevant things. This allows these typedefs to be reused in other places without having to reinvent this preprocessor logic. llvm-svn: 334294
* Add a file open flag that disables O_CLOEXEC.Zachary Turner2018-06-081-5/+15
| | | | | | | | | | | O_CLOEXEC is the right default, but occasionally you don't want this. This is especially true for tools like debuggers where you might need to spawn the child process with specific files already open, but it's occasionally useful in other scenarios as well, like when you want to do some IPC between parent and child. llvm-svn: 334293
* Expose a single global file open function.Zachary Turner2018-06-071-51/+37
| | | | | | | | | This one allows much more flexibility than the standard openFileForRead / openFileForWrite functions. Since there is now just one "real" function that does the work, all other implementations simply delegate to this one. llvm-svn: 334246
* [FileSystem] Split up the OpenFlags enumeration.Zachary Turner2018-06-072-84/+123
| | | | | | | | | | | | | | | | | 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] Add functions that operate on native file handles on Windows.Zachary Turner2018-06-041-30/+49
| | | | | | | | | | | | | | | | | | | | Windows' CRT has a limit of 512 open file descriptors, and fds which are generated by converting a HANDLE via _get_osfhandle count towards this limit as well. Regardless, often you find yourself marshalling back and forth between native HANDLE objects and fds anyway. If we know from the getgo that we're going to need to work directly with the handle, we can cut out the marshalling layer while also not contributing to filling up the CRT's very limited handle table. On Unix these functions just delegate directly to the existing set of functions since an fd *is* the native file type. It would be nice, very long term, if we could convert most uses of fds to file_t. Differential Revision: https://reviews.llvm.org/D47688 llvm-svn: 333945
* Move some function declarations out of WindowsSupport.hZachary Turner2018-06-016-14/+5
| | | | | | | | | | | | | | | | | | The idea behind WindowsSupport.h is that it's in the source directory so that windows.h'isms don't leak out into the larger LLVM project. To that end, any symbol that references a symbol from windows.h must be in this private header, and not in a public header. However, we had some useful utility functions in WindowsSupport.h which have no dependency on the Windows API, but still only make sense on Windows. Those functions should be usable outside of Support since there is no risk of causing a windows.h leak. Although this introduces some preprocessor logic in some header files, It's not too egregious and it's better than the alternative of duplicating a ton of code. Differential Revision: https://reviews.llvm.org/D47662 llvm-svn: 333798
* [Support] Avoid normalization in sys::getDefaultTargetTriplePetr Hosek2018-05-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | The return value of sys::getDefaultTargetTriple, which is derived from -DLLVM_DEFAULT_TRIPLE, is used to construct tool names, default target, and in the future also to control the search path directly; as such it should be used textually, without interpretation by LLVM. Normalization of this value may lead to unexpected results, for example if we configure LLVM with -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-linux-gnu, normalization will transform that value to x86_64--linux-gnu. Driver will use that value to search for tools prefixed with x86_64--linux-gnu- which may be confusing. This is also inconsistent with the behavior of the --target flag which is taken as-is without any normalization and overrides the value of LLVM_DEFAULT_TARGET_TRIPLE. Users of sys::getDefaultTargetTriple already perform their own normalization as needed, so this change shouldn't impact existing logic. Differential Revision: https://reviews.llvm.org/D47153 llvm-svn: 333307
* Revert 332750, llvm part (see comment on D46910).Nico Weber2018-05-201-1/+1
| | | | llvm-svn: 332823
* [Support] Avoid normalization in sys::getDefaultTargetTriplePetr Hosek2018-05-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | The return value of sys::getDefaultTargetTriple, which is derived from -DLLVM_DEFAULT_TRIPLE, is used to construct tool names, default target, and in the future also to control the search path directly; as such it should be used textually, without interpretation by LLVM. Normalization of this value may lead to unexpected results, for example if we configure LLVM with -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-linux-gnu, normalization will transform that value to x86_64--linux-gnu. Driver will use that value to search for tools prefixed with x86_64--linux-gnu- which may be confusing. This is also inconsistent with the behavior of the --target flag which is taken as-is without any normalization and overrides the value of LLVM_DEFAULT_TARGET_TRIPLE. Users of sys::getDefaultTargetTriple already perform their own normalization as needed, so this change shouldn't impact existing logic. Differential Revision: https://reviews.llvm.org/D46910 llvm-svn: 332750
* Signal handling should be signal-safeJF Bastien2018-05-161-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch, signal handling wasn't signal safe. This leads to real-world crashes. It used ManagedStatic inside of signals, this can allocate and can lead to unexpected state when a signal occurs during llvm_shutdown (because llvm_shutdown destroys the ManagedStatic). It also used cl::opt without custom backing storage. Some de-allocation was performed as well. Acquiring a lock in a signal handler is also a great way to deadlock. We can't just disable signals on llvm_shutdown because the signals might do useful work during that shutdown. We also can't just disable llvm_shutdown for programs (instead of library uses of clang) because we'd have to then mark the pointers as not leaked and make sure all the ManagedStatic uses are OK to leak and remain so. Move all of the code to lock-free datastructures instead, and avoid having any of them in an inconsistent state. I'm not trying to be fancy, I'm not using any explicit memory order because this code isn't hot. The only purpose of the atomics is to guarantee that a signal firing on the same or a different thread doesn't see an inconsistent state and crash. In some cases we might miss some state (for example, we might fail to delete a temporary file), but that's fine. Note that I haven't touched any of the backtrace support despite it not technically being totally signal-safe. When that code is called we know something bad is up and we don't expect to continue execution, so calling something that e.g. sets errno is the least of our problems. A similar patch should be applied to lib/Support/Windows/Signals.inc, but that can be done separately. Fix r332428 which I reverted in r332429. I originally used double-wide CAS because I was lazy, but some platforms use a runtime function for that which thankfully failed to link (it would have been bad for signal handlers otherwise). I use a separate flag to guard the data instead. <rdar://problem/28010281> Reviewers: dexonsmith Subscribers: steven_wu, llvm-commits llvm-svn: 332496
* Revert "Signal handling should be signal-safe"JF Bastien2018-05-161-3/+2
| | | | | | Some bots don't have double-pointer width compare-and-exchange. Revert for now.q llvm-svn: 332429
* Signal handling should be signal-safeJF Bastien2018-05-161-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch, signal handling wasn't signal safe. This leads to real-world crashes. It used ManagedStatic inside of signals, this can allocate and can lead to unexpected state when a signal occurs during llvm_shutdown (because llvm_shutdown destroys the ManagedStatic). It also used cl::opt without custom backing storage. Some de-allocation was performed as well. Acquiring a lock in a signal handler is also a great way to deadlock. We can't just disable signals on llvm_shutdown because the signals might do useful work during that shutdown. We also can't just disable llvm_shutdown for programs (instead of library uses of clang) because we'd have to then mark the pointers as not leaked and make sure all the ManagedStatic uses are OK to leak and remain so. Move all of the code to lock-free datastructures instead, and avoid having any of them in an inconsistent state. I'm not trying to be fancy, I'm not using any explicit memory order because this code isn't hot. The only purpose of the atomics is to guarantee that a signal firing on the same or a different thread doesn't see an inconsistent state and crash. In some cases we might miss some state (for example, we might fail to delete a temporary file), but that's fine. Note that I haven't touched any of the backtrace support despite it not technically being totally signal-safe. When that code is called we know something bad is up and we don't expect to continue execution, so calling something that e.g. sets errno is the least of our problems. A similar patch should be applied to lib/Support/Windows/Signals.inc, but that can be done separately. <rdar://problem/28010281> Reviewers: dexonsmith Subscribers: aheejin, llvm-commits Differential Revision: https://reviews.llvm.org/D46858 llvm-svn: 332428
* [NFC] Update commentsJF Bastien2018-05-151-11/+11
| | | | | | Don't prepend function or data name before each comment. Split into its own NFC patch as requested in D46858. llvm-svn: 332323
* [Support] Add docs for 'openFileFor{Write,Read}'Brian Gesiak2018-05-111-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add documentation for the LLVM Support functions `openFileForWrite` and `openFileForRead`. The `openFileForRead` parameter `RealPath`, in particular, I think warranted some explanation. In addition, make the behavior of the functions more consistent across platforms. Prior to this patch, Windows would set or not set the result file descriptor based on the nature of the error, whereas Unix would consistently set it to `-1` if the open failed. Make Windows consistently set it to `-1` as well. Test Plan: 1. `ninja check-llvm` 2. `ninja docs-llvm-html` Reviewers: zturner, rnk, danielmartin, scanon Reviewed By: danielmartin, scanon Subscribers: scanon, danielmartin, llvm-commits Differential Revision: https://reviews.llvm.org/D46499 llvm-svn: 332075
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-012-5/+5
| | | | | | | | | | | | | | | | We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
* [support] Revert the changes made to Path.inc for the default Windows code pageAaron Smith2018-04-181-11/+5
| | | | | | | | | Path.inc/widenPath tries to decode the path using both UTF-8 and the default Windows code page. This is no longer necessary with the new InitLLVM method which ensures that the command line arguemnts are already UTF-8 on Windows. llvm-svn: 330266
* Rename sys::Process::GetArgumentVector -> sys::windows::GetCommandLineArgumentsRui Ueyama2018-04-172-27/+31
| | | | | | | | | | | | | | GetArgumentVector (or GetCommandLineArguments) is very Windows-specific. I think it doesn't make much sense to provide that function from sys::Process. I also made a change so that the function takes a BumpPtrAllocator instead of a SpecificBumpPtrAllocator. The latter is the class to call dtors, but since char * is trivially destructible, we should use the former class. Differential Revision: https://reviews.llvm.org/D45641 llvm-svn: 330216
* [Support] Fix building for Windows on ARMMartin Storsjo2018-04-131-1/+9
| | | | | | | | | | | The commit in SVN r310001 that added support for this actually didn't use the right struct field for the frame pointer - for ARM, there is no register named Fp in the CONTEXT struct. On Windows, the R11 register is used as frame pointer. Differential Revision: https://reviews.llvm.org/D45590 llvm-svn: 329991
* Windows needs the current codepage instead of utf8 sometimesAaron Smith2018-04-072-28/+52
| | | | | | | | | | | | | | | | Llvm-mc (and tools that use Path.inc on Windows) assume that strings are utf-8 encoded, however, this is not always the case. On Windows the default codepage is not utf-8, so most of the time the strings are not utf-8 encoded. The lld test 'format-binary-non-ascii' uses llvm-mc with a file with non-ascii characters in the name which is how this bug was found. The test fails when run using Python 3 because it uses properly encoded unicode strings (Python 2 actually ends up using a byte string which is not utf-8 encoded, so the test passes, but that's separate issue). Patch by Stella Stamenova! llvm-svn: 329468
* Remove HAVE_LIBPSAPI, HAVE_SHELL32.Nico Weber2018-04-022-11/+1
| | | | | | | | | | These used to be set in the old autoconf build, but the cmake build has had a "TODO: actually check for these" comment since it was checked in, and they were set to 1 on mingw unconditionally. It seems safe to say that they always exist under mingw, so just remove them and assume they're set exactly when on mingw (with msvc, we use `pragma comment` instead of linking these via flags). llvm-svn: 328992
* [Support] Add WriteThroughMemoryBuffer.Zachary Turner2018-03-081-1/+1
| | | | | | | | | | | This is like MemoryBuffer (read-only) and WritableMemoryBuffer (writable private), but where the underlying file can be modified after writing. This is useful when you want to open a file, make some targeted edits, and then write it back out. Differential Revision: https://reviews.llvm.org/D44230 llvm-svn: 327057
* Report fatal error in the case of out of memorySerge Pavlov2018-02-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the second part of recommit of r325224. The previous part was committed in r325426, which deals with C++ memory allocation. Solution for C memory allocation involved functions `llvm::malloc` and similar. This was a fragile solution because it caused ambiguity errors in some cases. In this commit the new functions have names like `llvm::safe_malloc`. The relevant part of original comment is below, updated for new function names. Analysis of fails in the case of out of memory errors can be tricky on Windows. Such error emerges at the point where memory allocation function fails, but manifests itself when null pointer is used. These two points may be distant from each other. Besides, next runs may not exhibit allocation error. In some cases memory is allocated by a call to some of C allocation functions, malloc, calloc and realloc. They are used for interoperability with C code, when allocated object has variable size and when it is necessary to avoid call of constructors. In many calls the result is not checked for null pointer. To simplify checks, new functions are defined in the namespace 'llvm': `safe_malloc`, `safe_calloc` and `safe_realloc`. They behave as corresponding standard functions but produce fatal error if allocation fails. This change replaces the standard functions like 'malloc' in the cases when the result of the allocation function is not checked for null pointer. Finally, there are plain C code, that uses malloc and similar functions. If the result is not checked, assert statement is added. Differential Revision: https://reviews.llvm.org/D43010 llvm-svn: 325551
* Call FlushFileBuffers on output files.Zachary Turner2018-02-151-1/+15
| | | | | | | | | | | | There is a latent Windows kernel bug, the exact trigger conditions are not well understood, which can cause a file to be correctly written, but unable to be correctly read. The workaround appears to be simply calling FlushFileBuffers. Differential Revision: https://reviews.llvm.org/D42925 llvm-svn: 325274
* Revert r325224 "Report fatal error in the case of out of memory"Serge Pavlov2018-02-151-2/+2
| | | | | | It caused fails on some buildbots. llvm-svn: 325227
* Report fatal error in the case of out of memorySerge Pavlov2018-02-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Analysis of fails in the case of out of memory errors can be tricky on Windows. Such error emerges at the point where memory allocation function fails, but manifests itself when null pointer is used. These two points may be distant from each other. Besides, next runs may not exhibit allocation error. Usual programming practice does not require checking result of 'operator new' because it throws 'std::bad_alloc' in the case of allocation error. However, LLVM is usually built with exceptions turned off, so 'new' can return null pointer. This change installs custom new handler, which causes fatal error in the case of out of memory. The handler is installed automatically prior to call to 'main' during construction of a static object defined in 'lib/Support/ErrorHandling.cpp'. If the application does not use this file, the handler may be installed manually by a call to 'llvm::install_out_of_memory_new_handler', declared in 'include/llvm/Support/ErrorHandling.h". There are calls to C allocation functions, malloc, calloc and realloc. They are used for interoperability with C code, when allocated object has variable size and when it is necessary to avoid call of constructors. In many calls the result is not checked against null pointer. To simplify checks, new functions are defined in the namespace 'llvm' with the same names as these C function. These functions produce fatal error if allocation fails. User should use 'llvm::malloc' instead of 'std::malloc' in order to use the safe variant. This change replaces 'std::malloc' in the cases when the result of allocation function is not checked against null pointer. Finally, there are plain C code, that uses malloc and similar functions. If the result is not checked, assert statements are added. Differential Revision: https://reviews.llvm.org/D43010 llvm-svn: 325224
* Typo fix SIBABRT -> SIGABRT.Eric Christopher2018-01-181-1/+1
| | | | | | Based on a patch by Henry Wong! llvm-svn: 322902
* Delete temp file if rename fails.Rafael Espindola2017-12-051-5/+17
| | | | | | | | | | | | | | | | | | | Without this when lld failed to replace the output file it would leave the temporary behind. The problem is that the existing logic is - cancel the delete flag - rename We have to cancel first to avoid renaming and then crashing and deleting the old version. What is missing then is deleting the temporary file if the rename fails. This can be an issue on both unix and windows, but I am not sure how to cause the rename to fail reliably on unix. I think it can be done on ZFS since it has an ACL system similar to what windows uses, but adding support for checking that in llvm-lit is probably not worth it. llvm-svn: 319786
* Use FILE_FLAG_DELETE_ON_CLOSE for TempFile on windows.Rafael Espindola2017-11-281-3/+58
| | | | | | We won't see the temp file no more. llvm-svn: 319137
* Add an F_Delete flag.Rafael Espindola2017-11-281-0/+2
| | | | | | For now this only changes the handle Access. llvm-svn: 319121
* move static function. NFCRafael Espindola2017-11-211-26/+24
| | | | llvm-svn: 318729
* Split a rename_handle out of rename on windows.Rafael Espindola2017-11-211-3/+13
| | | | llvm-svn: 318725
* Reorder static functions. NFC.Rafael Espindola2017-11-181-38/+35
| | | | llvm-svn: 318584
* Split realPathFromHandle in two.Rafael Espindola2017-11-181-13/+17
| | | | | | | By having an UTF-16 version we avoid some code duplication in calling GetFinalPathNameByHandleW. llvm-svn: 318583
* [Support] Support NetBSD PaX MPROTECT in sys::Memory.Lang Hames2017-11-161-80/+0
| | | | | | | | | Removes AllocateRWX, setWritable and setExecutable from sys::Memory and standardizes on allocateMappedMemory / protectMappedMemory. The allocateMappedMemory method is updated to request full permissions for memory blocks so that they can be marked executable later. llvm-svn: 318464
* Fix some undefined beahvior in FileMapping.Zachary Turner2017-11-161-2/+2
| | | | | | | This was broken when building a 32-bit native toolchain, as shifting a size_t right by 32 is UB when sizeof(size_t) == 8. llvm-svn: 318462
* [support] allocate exact size required for mapping in Support/Windws/Path.incBob Haarman2017-11-101-2/+2
| | | | | | | | | | | | | | | | | | | Summary: zturner suggested that mapped_file_region::init() on Windows seems to create mappings that are larger than they need to be: Offset+Size instead of Size. Indeed, that appears to be the case. I confirmed that tests pass with mappings of just Size bytes, and fail with Size-1 bytes, suggesting that Size is indeed the correct value. Reviewers: amccarth, zturner Reviewed By: zturner Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D39876 llvm-svn: 317850
* [support] remove tautological comparison in Support/Windows/Path.incBob Haarman2017-10-271-4/+0
| | | | | | | | | | | | | | | | | Summary: The removed code checks that we are able to handle a 64-bit number, but the code we're calling takes two dwords (for a total of 64 bits), so this is always true. Reviewers: zturner, rnk, majnemer, compnerd Reviewed By: zturner Subscribers: amccarth, hiraditya, lebedev.ri, llvm-commits Differential Revision: https://reviews.llvm.org/D39263 llvm-svn: 316814
* Work around lack of Wine support for SetFileInformationByHandle harderHans Wennborg2017-10-121-2/+7
| | | | | | | | | | In r315079 I added a check for the ERROR_CALL_NOT_IMPLEMENTED error code, but it turns out earlier versions of Wine just returned false without setting any error code. This patch handles the unset error code case. llvm-svn: 315597
* Support: Work around missing SetFileInformationByHandle on WineHans Wennborg2017-10-111-0/+11
| | | | | | | | | | In r315079, fs::rename was reimplemented in terms of CreateFile and SetFileInformationByHandle. Unfortunately, the latter isn't supported by Wine. This adds a fallback to MoveFileEx for that case. Differential Revision: https://reviews.llvm.org/D38817 llvm-svn: 315520
* WIN32_FIND_DATA -> WIN32_FIND_DATAW.Peter Collingbourne2017-10-111-1/+1
| | | | | | Should fix mingw bot. llvm-svn: 315413
* Support: Have directory_iterator::status() return ↵Peter Collingbourne2017-10-101-21/+40
| | | | | | | | | | | | | | | | | | FindFirstFileEx/FindNextFile results on Windows. This allows clients to avoid an unnecessary fs::status() call on each directory entry. Because the information returned by FindFirstFileEx is a subset of the information returned by a regular status() call, I needed to extract a base class from file_status that contains only that information. On my machine, this reduces the time required to enumerate a ThinLTO cache directory containing 520k files from almost 4 minutes to less than 2 seconds. Differential Revision: https://reviews.llvm.org/D38716 llvm-svn: 315378
* Support: On Windows, use CreateFileW to delete files in sys::fs::remove().Peter Collingbourne2017-10-101-16/+19
| | | | | | | | This saves a call to stat(). Differential Revision: https://reviews.llvm.org/D38715 llvm-svn: 315351
* Fix after r315079Adrian McCarthy2017-10-091-1/+1
| | | | | | | | | | | | Microsoft's debug implementation of std::copy checks if the destination is an array and then does some bounds checking. This was causing an assertion failure in fs::rename_internal which copies to a buffer of the appropriate size but that's type-punned to an array of length 1 for API compatibility reasons. Fix is to make make the destination a pointer rather than an array. llvm-svn: 315222
OpenPOWER on IntegriCloud