summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Windows/Program.inc
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
* Fix issues reported by -Wrange-loop-analysis when building with latest Clang ↵Alexandre Ganea2020-01-071-1/+1
| | | | | | (trunk). NFC. Fixes warning: loop variable 'E' of type 'const llvm::StringRef' creates a copy from type 'const llvm::StringRef' [-Wrange-loop-analysis]
* 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
* 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-0/+19
| | | | | | | | | | | | | | | | | 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
* [Support] Quote arguments containing \n on WindowsReid Kleckner2018-09-111-1/+1
| | | | | | | | | Fixes at_file.c test failure caused by r341988. We may want to change how we treat \n in our tokenizer, but this is probably a good fix regardless, since we can invoke all kinds of programs with different interpretations of the command line quoting rules. llvm-svn: 341992
* 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-101-115/+72
| | | | | | | | | | | | | | | | | | 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-101-72/+115
| | | | | | | | | 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-101-115/+72
| | | | | | | | | 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
* [FileSystem] Split up the OpenFlags enumeration.Zachary Turner2018-06-071-1/+1
| | | | | | | | | | | | | | | | | 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
* Move some function declarations out of WindowsSupport.hZachary Turner2018-06-011-0/+1
| | | | | | | | | | | | | | | | | | 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
* Convenience/safety fix for llvm::sys::Execute(And|No)WaitAlexander Kornienko2017-09-131-4/+5
| | | | | | | | | | | | | | | | | | | | Summary: Change the type of the Redirects parameter of llvm::sys::ExecuteAndWait, ExecuteNoWait and other APIs that wrap them from `const StringRef **` to `ArrayRef<Optional<StringRef>>`, which is safer and simplifies the use of these APIs (no more local StringRef variables just to get a pointer to). Corresponding clang changes will be posted as a separate patch. Reviewers: bkramer Reviewed By: bkramer Subscribers: vsk, llvm-commits Differential Revision: https://reviews.llvm.org/D37563 llvm-svn: 313155
* Minor style fixes in lib/Support/**/Program.(inc|cpp).Alexander Kornienko2017-09-061-28/+28
| | | | | | No functional changes intended. llvm-svn: 312646
* Remove more name space pollution from .inc filesKristof Beyls2017-03-311-1/+0
| | | | llvm-svn: 299222
* [Clang/Support/Windows/Unix] Command lines created by clang may exceed the ↵Oleg Ranevskyy2016-01-051-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | command length limit set by the OS Summary: Hi Rafael, Would you be able to review this patch, please? (Clang part of the patch is D15832). When clang runs an external tool, e.g. a linker, it may create a command line that exceeds the length limit. Clang uses the llvm::sys::argumentsFitWithinSystemLimits function to check if command line length fits the OS limitation. There are two problems in this function that may cause exceeding of the limit: 1. It ignores the length of the program path in its calculations. On the other hand, clang adds the program path to the command line when it runs the program. 2. It assumes no space character is inserted after the last argument, which is not true for Windows. The flattenArgs function adds the trailing space for *each* argument. The result of this is that the terminating NULL character is not counted and may be placed beyond the length limit if the command line is exactly 32768 characters long. The WinAPI's CreateProcess does not find the NULL character and fails. Reviewers: rafael, ygao, probinson Subscribers: asl, llvm-commits Differential Revision: http://reviews.llvm.org/D15831 llvm-svn: 256866
* Add Windows error code and tidy formatting for system errors.Paul Robinson2015-11-231-3/+3
| | | | | | Differential Revision: http://reviews.llvm.org/D14892 llvm-svn: 253888
* Windows: Fixed sys::findProgramByName to work with files containing dot in ↵George Rimar2015-10-081-2/+9
| | | | | | | | | | | | their name. Problem was in SearchPathW function that does not attach an extension if file already has one. That does not work for executables like ld.lld2 for example which require to have .exe extension but SearchPath thinks that its "lld2". Solution was to add the extension manually. Differential Revision: http://reviews.llvm.org/D13536 llvm-svn: 249696
* Add .exe check to Execute to fix clang-modernize tests broken in r247358Reid Kleckner2015-09-101-0/+8
| | | | llvm-svn: 247361
* Don't use std::errc.Rafael Espindola2015-06-131-1/+2
| | | | | | | | | | | | | | | | | | | | | As noted on Errc.h: // * std::errc is just marked with is_error_condition_enum. This means that // common patters like AnErrorCode == errc::no_such_file_or_directory take // 4 virtual calls instead of two comparisons. And on some libstdc++ those virtual functions conclude that ------------------------ int main() { std::error_code foo = std::make_error_code(std::errc::no_such_file_or_directory); return foo == std::errc::no_such_file_or_directory; } ------------------------- should exit with 0. llvm-svn: 239683
* Revert r235177 as the Handle is used to fail GetExitCodeProcess on purpose.Yaron Keren2015-04-171-1/+3
| | | | | | | Avoid double closing of the handle by testing GetLastErr for ERROR_INVALID_HANDLE and not calling CloseHandle(PI.ProcessHandle) then. llvm-svn: 235184
* Eliminate superfluous CloseHandle(PI.ProcessHandle).Yaron Keren2015-04-171-1/+0
| | | | | | | This handle will always be closed few lines later, resulting in an error for the second CloseHandle. llvm-svn: 235177
* [cleanup] Re-sort all the #include lines in LLVM usingChandler Carruth2015-01-141-1/+1
| | | | | | | | | | | utils/sort_includes.py. I clearly haven't done this in a while, so more changed than usual. This even uncovered a missing include from the InstrProf library that I've added. No functionality changed here, just mechanical cleanup of the include order. llvm-svn: 225974
* Fix several bugs in r221220's new program finding code.Chandler Carruth2014-12-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | In both the Unix and Windows variants, std::getenv was called and the result passed directly to a function accepting a StringRef. This isn't OK because it might return a null pointer and that causes the StringRef constructor to assert (and generally produces crash-prone code if asserts are disabled). Fix this by independently testing the result as non-null prior to splitting things. This in turn uncovered another bug in the Unix variant where it would infinitely recurse if PATH="", or after this fix if PATH isn't set. There is no need to recurse at all. Slightly re-arrange the code to make it clear that we can just fixup the Paths argument based on the environment if we find anything. I don't know of a particularly useful way to test these routines in LLVM. I'll commit a test to Clang that ensures that its driver correctly handles various settings of PATH. However, I have no idea how to correctly write a Windows test for the PATHEXT change. Any Windows developers who could provide such a test, please have at. =D Many thanks to Nick Lewycky and others for helping debug this. =/ It was quite nasty for us to track down. llvm-svn: 223099
* More long path name support on Windows, this time in program execution.Paul Robinson2014-11-241-5/+10
| | | | | | | Allows long paths for the executable and redirected stdin/stdout/stderr. Addresses PR21563. llvm-svn: 222671
* Avoid usage of char16_t as MSVC "14" doesn't appear to support itReid Kleckner2014-11-131-4/+4
| | | | | | Fixes the MSVC "14" build. llvm-svn: 221932
* Remove FindProgramByName. NFC.Rafael Espindola2014-11-041-39/+0
| | | | llvm-svn: 221258
* Fix Visual C++ warning, Program.inc(85): warning C4018: '<' : ↵Yaron Keren2014-11-041-1/+1
| | | | | | signed/unsigned mismatch. llvm-svn: 221252
* sys::findProgramByName(): [Win32] Tweak to pass lowercase .exe to ↵NAKAMURA Takumi2014-11-041-0/+1
| | | | | | | | | SearchPath() to appease clang Driver's tests. It seems SearchPath() doesn't show actual extension on the filesystem. FIXME: Shall we use FindFirstFile() here? llvm-svn: 221246
* [Support][Program] Add findProgramByName(Name, OptionalPaths)Michael J. Spencer2014-11-041-0/+64
| | | | llvm-svn: 221220
* clang-format of ChangeStdinToBinary & ChangeStdoutToBinary.Yaron Keren2014-09-261-4/+4
| | | | llvm-svn: 218547
* Add writeFileWithSystemEncoding to LibLLVMSuppor.Rafael Espindola2014-09-031-0/+46
| | | | | | | | | | | | | | | | | | | | 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
* Refactor argument serialization logic when executing process. NFC.Rafael Espindola2014-08-251-13/+17
| | | | | | | | | | | | This patch refactors the argument serialization logic used in the Execute function, used to launch new Windows processes. There is a critical step that joins char** arguments into a single string, building the command line used to launch the new process, and the readability of this code is improved if this part is refactored in its own helper function. Patch by Rafael Auler! llvm-svn: 216411
* Remove 'using std::errro_code' from lib.Rafael Espindola2014-06-131-10/+9
| | | | llvm-svn: 210871
* Don't use 'using std::error_code' in include/llvm.Rafael Espindola2014-06-121-0/+1
| | | | | | This should make sure that most new uses use the std prefix. llvm-svn: 210835
* Prefix generic_category with std::.Rafael Espindola2014-06-121-2/+2
| | | | | | Sorry I missed these before. llvm-svn: 210740
* Fix windows build.Rafael Espindola2014-05-311-2/+2
| | | | llvm-svn: 209961
* Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles2014-03-061-2/+1
| | | | | | | | | | This compiles with no changes to clang/lld/lldb with MSVC and includes overloads to various functions which are used by those projects and llvm which have OwningPtr's as parameters. This should allow out of tree projects some time to move. There are also no changes to libs/Target, which should help out of tree targets have time to move, if necessary. llvm-svn: 203083
* Delete dead code.Rafael Espindola2014-02-241-7/+0
| | | | llvm-svn: 202001
* Rename Windows.h to WindowsSupport.h to avoid ambiguityReid Kleckner2014-02-121-1/+1
| | | | llvm-svn: 201258
* Fix initialization order warning in mingw32 buildAlp Toker2013-10-181-1/+1
| | | | | | No change in functionality. llvm-svn: 192953
* Windows: Be more explicit with Win32 APIsDavid Majnemer2013-10-071-1/+1
| | | | | | | | | | | | This addresses several issues in a similar vein: - Use the Unicode APIs when possible, running nm on clang shows that we only use Unicode APIs except for FormatMessage, CreateSemaphore, and GetModuleHandle. AFAICT, the latter two are coming from MinGW and not LLVM itself. - Make getMainExecutable more resilient. It previously considered return values of zero from ::GetModuleFileNameA to be acceptable. llvm-svn: 192096
* Revert "Revert "Windows: Add support for unicode command lines""David Majnemer2013-10-071-54/+72
| | | | | | | This reverts commit r192070 which reverted r192069, I forgot to regenerate the configure scripts. llvm-svn: 192079
* Revert "Windows: Add support for unicode command lines"David Majnemer2013-10-061-72/+54
| | | | | | | This is causing MinGW bots to fail. This reverts commit r192069. llvm-svn: 192070
* Windows: Add support for unicode command linesDavid Majnemer2013-10-061-54/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The MSVCRT deliberately sends main() code-page specific characters. This isn't too useful to LLVM as we end up converting the arguments to UTF-16 and subsequently attempt to use the result as, for example, a file name. Instead, we need to have the ability to access the Unicode command line and transform it to UTF-8. This has the distinct advantage over using the MSVC-specific wmain() function as our entry point because: - It doesn't work on cygwin. - It only work on MinGW with caveats and only then on certain versions. - We get to keep our entry point as main(). :) N.B. This patch includes fixes to other parts of lib/Support/Windows s.t. we would be able to take advantage of getting the Unicode paths. E.G. clang spawning clang -cc1 would want to give it Unicode arguments. Reviewers: aaron.ballman, Bigcheese, rnk, ruiu Reviewed By: rnk CC: llvm-commits, ygao Differential Revision: http://llvm-reviews.chandlerc.com/D1834 llvm-svn: 192069
* Add non-blocking Wait() for launched processesTareq A. Siraj2013-10-011-61/+52
| | | | | | | | | | | | | | | | | - New ProcessInfo class to encapsulate information about child processes. - Generalized the Wait() to support non-blocking wait on child processes. - ExecuteNoWait() now returns a ProcessInfo object with information about the launched child. Users will be able to use this object to perform non-blocking wait. - ExecuteNoWait() now accepts an ExecutionFailed param that tells if execution failed or not. These changes will allow users to implement basic process parallel tools. Differential Revision: http://llvm-reviews.chandlerc.com/D1728 llvm-svn: 191763
* Avoid using alloca in Windows/Program.incReid Kleckner2013-08-071-13/+15
| | | | | | | One use needs to copy the alloca into a std::string, and the other use is before calling CreateProcess, which is very heavyweight anyway. llvm-svn: 187845
OpenPOWER on IntegriCloud