summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Windows/WindowsSupport.h
Commit message (Collapse)AuthorAgeFilesLines
* llvm-ar: Fix MinGW compilationHans Wennborg2020-02-281-243/+0
| | | | | | | | | | | | | | | | 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
* Reland "[Support] Add a way to run a function on a detached thread""Sam McCall2019-10-231-0/+8
| | | | | This reverts commit 7bc7fe6b789d25d48d6dc71d533a411e9e981237. The immediate callers have been fixed to pass nullopt where appropriate.
* Revert "[Support] Add a way to run a function on a detached thread"Sam McCall2019-10-231-8/+0
| | | | | | This reverts commit 40668abca4d307e02b33345cfdb7271549ff48d0. This causes clang tests to fail, as stacksize=0 is being explicitly passed and is no longer a no-op.
* [Support] Add a way to run a function on a detached threadSam McCall2019-10-231-0/+8
| | | | | | | | | | | | | | | | | | | | | | | This roughly mimics `std::thread(...).detach()` except it allows to customize the stack size. Required for https://reviews.llvm.org/D50993. I've decided against reusing the existing `llvm_execute_on_thread` because it's not obvious what to do with the ownership of the passed function/arguments: 1. If we pass possibly owning functions data to `llvm_execute_on_thread`, we'll lose the ability to pass small non-owning non-allocating functions for the joining case (as it's used now). Is it important enough? 2. If we use the non-owning interface in the new use case, we'll force clients to transfer ownership to the spawned thread manually, but similar code would still have to exist inside `llvm_execute_on_thread(_async)` anyway (as we can't just pass the same non-owning pointer to pthreads and Windows implementations, and would be forced to wrap it in some structure, and deal with its ownership. Patch by Dmitry Kozhevnikov! Differential Revision: https://reviews.llvm.org/D51103
* Move endian constant from Host.h to SwapByteOrder.h, prune includeReid Kleckner2019-10-191-0/+1
| | | | | | | | | | | | | | Works on this dependency chain: ArrayRef.h -> Hashing.h -> --CUT-- Host.h -> StringMap.h / StringRef.h ArrayRef is very popular, but Host.h is rarely needed. Move the IsBigEndianHost constant to SwapByteOrder.h. Clients of that header are more likely to need it. llvm-svn: 375316
* 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
* [Windows] Simplify WindowsSupport.hReid Kleckner2018-11-061-82/+11
| | | | | | | | | | | | | | | | | Sink Windows version detection code from WindowsSupport.h to Path.inc. These functions don't need to be inlined. I randomly picked Process.inc for the Windows version helpers, since that's the most related file. Sink MakeErrMsg to Program.inc since it's the main client. Move those functions into the llvm namespace, and delete the scoped handle copy and assignment operators. Reviewers: zturner, aganea Differential Revision: https://reviews.llvm.org/D54182 llvm-svn: 346280
* Silence deprecation warning for GetVersionEx with clang-clReid Kleckner2018-11-061-0/+7
| | | | llvm-svn: 346268
* [Support] Fix `warning: unknown pragma ignored` for mingw targetMartin Storsjo2018-11-061-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D54133 llvm-svn: 346218
* Only call FlushFileBuffers() when writing executables on WindowsAlexandre Ganea2018-11-051-0/+35
| | | | | | | | | | | | This is a follow-up for "r325274: Call FlushFileBuffers on output files." Previously, FlushFileBuffers() was called in all cases when writing a file. The objective was to go around a bug in the Windows kernel (as described here: https://randomascii.wordpress.com/2018/02/25/compiler-bug-linker-bug-windows-kernel-bug/). However that is required only when writing EXEs, any other file type doesn't need flushing. This patch calls FlushFileBuffers() only for EXEs. In addition, we completly disable FlushFileBuffers() for known Windows 10 versions that do not exhibit the original kernel bug. Differential Revision: https://reviews.llvm.org/D53727 llvm-svn: 346152
* Move some function declarations out of WindowsSupport.hZachary Turner2018-06-011-14/+0
| | | | | | | | | | | | | | | | | | 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
* Rename sys::Process::GetArgumentVector -> sys::windows::GetCommandLineArgumentsRui Ueyama2018-04-171-0/+6
| | | | | | | | | | | | | | 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
* Windows needs the current codepage instead of utf8 sometimesAaron Smith2018-04-071-0/+2
| | | | | | | | | | | | | | | | 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
* Fix one place where I missed a commented requirement for a particularChandler Carruth2017-06-061-1/+3
| | | | | | | | | include ordering. I've changed the structure so that clang-format will preserve this going forward. llvm-svn: 304788
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* Removed FIXME from include ordering commentSimon Pilgrim2016-10-241-1/+1
| | | | | | Nothing to fix, it's just the way it has to be. llvm-svn: 284991
* Fix windows builds by swapping windows.h and wincrypt.h ordering.Simon Pilgrim2016-10-241-1/+1
| | | | | | We need to include windows.h first even though it breaks default include ordering rules llvm-svn: 284968
* Remove TimeValue usage from llvm/SupportPavel Labath2016-10-241-3/+37
| | | | | | | | | | | | | | | | | Summary: This is a follow-up to D25416. It removes all usages of TimeValue from llvm/Support library (except for the actual TimeValue declaration), and replaces them with appropriate usages of std::chrono. To facilitate this, I have added small utility functions for converting time points and durations into appropriate OS-specific types (FILETIME, struct timespec, ...). Reviewers: zturner, mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25730 llvm-svn: 284966
* Explicitly specify the ANSI version of these Win32 APIs. While these are ↵Aaron Ballman2016-06-231-5/+5
| | | | | | seemingly unrelated changes, they are all NFC because we currently default to the ANSI versions of the APIs when building for Windows. This simply makes the ANSI usage explicit. llvm-svn: 273564
* [Support] Creation of minidump after compiler crash on WindowsLeny Kholodov2016-05-041-0/+17
| | | | | | | | | | | In the current implementation compiler only prints stack trace to console after crash. This patch adds saving of minidump files which contain a useful subset of the information for further debugging. Differential Revision: http://reviews.llvm.org/D18216 llvm-svn: 268519
* [NFC] Header cleanupMehdi Amini2016-04-181-1/+0
| | | | | | | | | | | | | | Removed some unused headers, replaced some headers with forward class declarations. Found using simple scripts like this one: clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap' Patch by Eugene Kosov <claprix@yandex.ru> Differential Revision: http://reviews.llvm.org/D19219 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266595
* Avoid the deprecated GetVersionEx APIReid Kleckner2016-01-111-9/+18
| | | | | | | | | Apparently the preferred version is the incredibly complicated VerifyVersionInfoW function. Rename the function to avoid potential future name clashes. llvm-svn: 257415
* Use ::GetVersionEx directly rather than the Win8.1 SDK helpersReid Kleckner2016-01-111-6/+4
| | | | | | | | This removes ifdefs and fixes the build for users of the Win8.0 SDK, which I happen to be. Upgrading is not hard, but executing the same code everywhere seems better. llvm-svn: 257379
* Do not define NOGDI. Mingw defines LOGFONTW type in wingdi.h and the mingwYunzhong Gao2016-01-061-1/+0
| | | | | | version of shlobj.h includes shobjidl.h and the latter uses the LOGFONTW type. llvm-svn: 256904
* Another attempt at fixing the i686-mingw32-RA-on-linux buildbot. I am gettingYunzhong Gao2016-01-061-4/+2
| | | | | | | | confused with what version of mingw is actually installed on the buildbot, and for now I will just assume this is an unknown version which does not ship with VersionHelpers.h. llvm-svn: 256902
* Another attempt at fixing the i686-mingw32-RA-on-linux buildbot.Yunzhong Gao2016-01-061-2/+3
| | | | llvm-svn: 256901
* Hopefully fix a mingw32 buildbot (i686-mingw32-RA-on-linux) which does not haveYunzhong Gao2016-01-061-1/+5
| | | | | | the VersionHelpers.h header. llvm-svn: 256896
* Fixing PR25717: fatal IO error writing large outputs to console on Windows.Yunzhong Gao2016-01-061-0/+16
| | | | | | | | | | | | | This patch is similar to the Python issue#11395. We need to cap the output size to 32767 on Windows to work around the size limit of WriteConsole(). Reference: https://bugs.python.org/issue11395 Writing a test for this bug turns out to be harder than I thought. I am still working on it (see phabricator review D15705). Differential Revision: http://reviews.llvm.org/D15553 llvm-svn: 256892
* Add Windows error code and tidy formatting for system errors.Paul Robinson2015-11-231-4/+8
| | | | | | Differential Revision: http://reviews.llvm.org/D14892 llvm-svn: 253888
* Require Windows API of version 6.1 (Windows 7).Pawel Bylica2015-10-151-3/+3
| | | | llvm-svn: 250413
* Removing LLVM_EXPLICIT, as MSVC 2012 was the last reason for requiring the ↵Aaron Ballman2015-02-151-1/+1
| | | | | | macro. NFC; LLVM edition. llvm-svn: 229335
* Add missing include guards to WindowsSupport.h.Yaron Keren2015-01-211-0/+5
| | | | llvm-svn: 226669
* More long path name support on Windows, this time in program execution.Paul Robinson2014-11-241-0/+6
| | | | | | | Allows long paths for the executable and redirected stdin/stdout/stderr. Addresses PR21563. llvm-svn: 222671
* Add writeFileWithSystemEncoding to LibLLVMSuppor.Rafael Espindola2014-09-031-0/+3
| | | | | | | | | | | | | | | | | | | | This patch adds to LLVMSupport the capability of writing files with international characters encoded in the current system encoding. This is relevant for Windows, where we can either use UTF16 or the current code page (the legacy Windows international characters). On UNIX, the file is always saved in UTF8. This will be used in a patch for clang to thoroughly support response files creation when calling other tools, addressing PR15171. On Windows, to correctly support internationalization, we need the ability to write response files both in UTF16 or the current code page, depending on the tool we will call. GCC for mingw, for instance, requires files to be encoded in the current code page. MSVC tools requires files to be encoded in UTF16. Patch by Rafael Auler! llvm-svn: 217068
* Trying to fix the windows build.Rafael Espindola2014-06-121-4/+3
| | | | llvm-svn: 210805
* Remove system_error.h.Rafael Espindola2014-06-121-1/+1
| | | | | | | This is a minimal change to remove the header. I will remove the occurrences of "using std::error_code" in a followup patch. llvm-svn: 210803
* Rename Windows.h to WindowsSupport.h to avoid ambiguityReid Kleckner2014-02-121-0/+172
llvm-svn: 201258
OpenPOWER on IntegriCloud