summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Windows/WindowsSupport.h
Commit message (Collapse)AuthorAgeFilesLines
* 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