summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Unix/Path.inc
Commit message (Collapse)AuthorAgeFilesLines
* [Support] Add error handling to sys::Process::getPageSize().Lang Hames2019-05-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes the return type of sys::Process::getPageSize to Expected<unsigned> to account for the fact that the underlying syscalls used to obtain the page size may fail (see below). For clients who use the page size as an optimization only this patch adds a new method, getPageSizeEstimate, which calls through to getPageSize but discards any error returned and substitues a "reasonable" page size estimate estimate instead. All existing LLVM clients are updated to call getPageSizeEstimate rather than getPageSize. On Unix, sys::Process::getPageSize is implemented in terms of getpagesize or sysconf, depending on which macros are set. The sysconf call is documented to return -1 on failure. On Darwin getpagesize is implemented in terms of sysconf and may also fail (though the manpage documentation does not mention this). These failures have been observed in practice when highly restrictive sandbox permissions have been applied. Without this patch, the result is that getPageSize returns -1, which wreaks havoc on any subsequent code that was assuming a sane page size value. <rdar://problem/41654857> Reviewers: dblaikie, echristo Subscribers: kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59107 llvm-svn: 360221
* Guard __builtin_available() with __has_builtin to support older host compilers.Adrian Prantl2019-05-071-1/+2
| | | | llvm-svn: 360174
* Try to use /proc on FreeBSD for getExecutablePathDavid Chisnall2019-04-291-1/+14
| | | | | | | | | | | Currently, clang's libTooling passes this function a fake argv0, which means that no libTooling tools can find the standard headers on FreeBSD. With this change, these will now work on any FreeBSD systems that have procfs mounted. This isn't the right fix for the libTooling issue, but it does bring the FreeBSD implementation of getExecutablePath closer to the Linux and macOS implementations. llvm-svn: 359427
* Revert using fcopyfile(3) to implement sys::fs::copy_file(Twine, int) on macOSAdrian Prantl2019-04-241-20/+4
| | | | | | | | | It turns out that I mesread the man page and fcopyfile(3) does not actually support COPYFILE_CLONE for files. <rdar://problem/50148757> llvm-svn: 359127
* Implement sys::fs::copy_file using the macOS copyfile(3) APIAdrian Prantl2019-04-181-0/+48
| | | | | | | | | | | | | | | | | | to support APFS clones. This patch adds a Darwin-specific implementation of llvm::sys::fs::copy_file() that uses the macOS copyfile(3) API to support APFS copy-on-write clones, which should be faster and much more space efficient. https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/APFS_Guide/ToolsandAPIs/ToolsandAPIs.html Differential Revision: https://reviews.llvm.org/D60802 This reapplies 358628 with an additional bugfix handling the case where the destination file already exists. (Caught by the clang testsuite). llvm-svn: 358716
* Revert Implement sys::fs::copy_file using the macOS copyfile(3) API to ↵Adrian Prantl2019-04-181-51/+0
| | | | | | | | | support APFS clones. This reverts r358628 (git commit 91a06bee788262a294527b815354f380d99dfa9b) while investigating a crash reproducer bot failure. llvm-svn: 358634
* Implement sys::fs::copy_file using the macOS copyfile(3) APIAdrian Prantl2019-04-181-0/+51
| | | | | | | | | | | | | | | to support APFS clones. This patch adds a Darwin-specific implementation of llvm::sys::fs::copy_file() that uses the macOS copyfile(3) API to support APFS copy-on-write clones, which should be faster and much more space efficient. https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/APFS_Guide/ToolsandAPIs/ToolsandAPIs.html Differential Revision: https://reviews.llvm.org/D60802 llvm-svn: 358628
* [Support] On AIX, Check ENOTSUP on posix_fallocate instead of EOPNOTSUPPHubert Tong2019-04-041-1/+6
| | | | | | | | | | | | | | | | | | | | Summary: `posix_fallocate` can fail if the underlying filesystem does not support it; and, on AIX, such a failure is reported by a return value of `ENOTSUP`. The existing code checks only for `EOPNOTSUPP`, which may share the same value as `ENOTSUP`, but is not required to. Reviewers: xingxue, sfertile, jasonliu Reviewed By: xingxue Subscribers: kristina, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60175 llvm-svn: 357662
* [Support] Implement is_local_impl with AIX mntctlHubert Tong2019-03-291-3/+45
| | | | | | | | | | | | | | | | | | | | | | Summary: On AIX, we can determine whether a filesystem is remote using `mntctl`. If the information is not found, then claim that the file is remote (since that is the more restrictive case). Testing for the associated interface is restored with a modified version of the unit test from rL295768. Reviewers: jasonliu, xingxue Reviewed By: xingxue Subscribers: jsji, apaprocki, Hahnfeld, zturner, krytarowski, kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58801 llvm-svn: 357333
* [Support] Treat truncation of fullpath as errorJonas Hahnfeld2019-03-131-1/+5
| | | | | | | | | | | | If the concatenation of arguments dir and bin has at least PATH_MAX characters the call to snprintf will truncate. The result will usually not exist, but if it does it's actually incorrect to return that the path exists. (Motivated by GCC compiler warning about format truncation.) Differential Revision: https://reviews.llvm.org/D58835 llvm-svn: 356036
* [llvm] [Support] Revert "Reimplement getMainExecutable() using sysctl on NetBSD"Michal Gorny2019-03-041-18/+2
| | | | | | | | | This apparently does not work reliably after all (non-reentrant?) and causes test failures such as: http://lab.llvm.org:8011/builders/netbsd-amd64/builds/19254/steps/run%20unit%20tests/logs/FAIL%3A%20libc%2B%2B%3A%3Asize.pass.cpp llvm-svn: 355302
* [llvm] [Support] Reimplement getMainExecutable() using sysctl on NetBSDMichal Gorny2019-03-031-2/+18
| | | | | | | | | | | | | | | | Use sysctl() to implement getMainExecutable() on NetBSD, rather than trying to guess the correct path from argv[0]. This is one of the fixes to recent clang-check-mac-libcxx-fixed-compilation-db.cpp test failure on NetBSD. This has been historically done on both FreeBSD and NetBSD in r303015, and reverted in r303285 due to buggy implementation on FreeBSD. However, FWIK the NetBSD implementation does not suffer from the same bugs and is more reliable than playing with argv[0]. Differential Revision: https://reviews.llvm.org/D56975 llvm-svn: 355283
* 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
* [Support] Fix GNU/kFreeBSD buildEli Friedman2018-12-181-1/+1
| | | | | | | | Patch by James Clarke. Differential Revision: https://reviews.llvm.org/D55296 llvm-svn: 349434
* [Support/FileSystem] Add sub-second precision for atime/mtime of ↵Argyrios Kyrtzidis2018-11-261-5/+16
| | | | | | | | | | | | | | | | | | | | sys::fs::file_status on unix platforms Summary: getLastAccessedTime() and getLastModificationTime() provided times in nanoseconds but with only 1 second resolution, even when the underlying file system could provide more precise times than that. These changes add sub-second precision for unix platforms that support improved precision. Also add some comments to make sure people are aware that the resolution of times can vary across different file systems. Reviewers: labath, zturner, aaron.ballman, kristina Reviewed By: aaron.ballman, kristina Subscribers: lebedev.ri, mgorny, kristina, llvm-commits Differential Revision: https://reviews.llvm.org/D54826 llvm-svn: 347530
* [FileSystem] Add expand_tilde functionJonas Devlieghere2018-11-131-0/+12
| | | | | | | | | | | | In D54435 there was some discussion about the expand_tilde flag for real_path that I wanted to expose through the VFS. The consensus is that these two things should be separate functions. Since we already have the code for this I went ahead and added a function expand_tilde that does just that. Differential revision: https://reviews.llvm.org/D54448 llvm-svn: 346776
* Fix DragonFlyBSD buildDavid Carlier2018-11-101-1/+3
| | | | | | | | | | Reviewers: rnk, thakis Reviewed By: krytarowski Differential Revision: https://reviews.llvm.org/D54363 llvm-svn: 346577
* Commit missing comment edit and use correct cast to fix std::min overloadReid Kleckner2018-10-231-5/+5
| | | | llvm-svn: 345105
* [hurd] Make getMainExecutable get the real binary pathReid Kleckner2018-10-231-7/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | On GNU/Hurd, llvm-config is returning bogus value, such as: $ llvm-config-6.0 --includedir /usr/include while it should be: $ llvm-config-6.0 --includedir /usr/lib/llvm-6.0/include This is because getMainExecutable does not get the actual installation path. On GNU/Hurd, /proc/self/exe is indeed a symlink to the path that was used to start the program, and not the eventual binary file. Llvm's getMainExecutable thus needs to run realpath over it to get the actual place where llvm was installed (/usr/lib/llvm-6.0/bin/llvm-config), and not /usr/bin/llvm-config-6.0. This will not change the result on Linux, where /proc/self/exe already points to the eventual file. Patch by Samuel Thibault! While making changes here, I reformatted this block a bit to reduce indentation and match 2 space indent style. Differential Revision: https://reviews.llvm.org/D53557 llvm-svn: 345104
* Add support for GNU Hurd in Path.inc and other placesSylvestre Ledru2018-10-231-3/+8
| | | | | | | | | | | | | | Summary: Patch by Svante Signell & myself Reviewers: rnk, JDevlieghere, efriedma Reviewed By: efriedma Subscribers: efriedma, JDevlieghere, krytarowski, llvm-commits, kristina Differential Revision: https://reviews.llvm.org/D53409 llvm-svn: 345007
* Remove dead function user_cache_directory()Nico Weber2018-09-181-23/+0
| | | | | | | | | | | | It's been unused since it was added almost 3 years ago in https://reviews.llvm.org/D13801 Motivated by https://reviews.llvm.org/rL342002 since it removes one of the functions keeping a ref to SHGetKnownFolderPath. Differential Revision: https://reviews.llvm.org/D52184 llvm-svn: 342485
* [Support] sys::fs::directory_entry includes the file_type.Kristina Brooks2018-09-121-33/+46
| | | | | | | | | | | | | | | | This is available on most platforms (Linux/Mac/Win/BSD) with no extra syscalls. On other platforms (e.g. Solaris) we stat() if this information is requested. This will allow switching clang's VFS to efficiently expose (path, type) when traversing a directory. Currently it exposes an entire Status, but does so by calling fs::status() on all platforms. Almost all callers only need the path, and all callers only need (path, type). Patch by sammccall (Sam McCall) Differential Revision: https://reviews.llvm.org/D51918 llvm-svn: 342089
* Use a lambda for calls to ::open in RetryAfterSignalHans Wennborg2018-08-271-2/+4
| | | | | | | | | | In Bionic, open can be overloaded for _FORTIFY_SOURCE support, causing compile errors of RetryAfterSignal due to overload resolution. Wrapping the call in a lambda avoids this. Based on a patch by Chih-Wei Huang <cwhuang@linux.org.tw>! llvm-svn: 340751
* [Support] NFC: Allow modifying access/modification times independently in ↵Jordan Rupprecht2018-08-131-4/+9
| | | | | | | | | | | | | | | | | sys::fs::setLastModificationAndAccessTime. Summary: Add an overload to sys::fs::setLastModificationAndAccessTime that allows setting last access and modification times separately. This will allow tools to use this API when they want to preserve both the access and modification times from an input file, which may be different. Also note that both the POSIX (futimens/futimes) and Windows (SetFileTime) APIs take the two timestamps in the order of (1) access (2) modification time, so this renames the method to "setLastAccessAndModificationTime" to make it clear which timestamp is which. For existing callers, the 1-arg overload just sets both timestamps to the same thing. Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50521 llvm-svn: 339628
* [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
* LTO: Keep file handles open for memory mapped files.Peter Collingbourne2018-06-131-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix build errors on some configurationsPavel Labath2018-06-111-1/+1
| | | | | | | | | | | | 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
* Cleanup. NFCFangrui Song2018-06-101-1/+1
| | | | llvm-svn: 334357
* Add a file open flag that disables O_CLOEXEC.Zachary Turner2018-06-081-4/+7
| | | | | | | | | | | 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-35/+14
| | | | | | | | | 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-071-44/+81
| | | | | | | | | | | | | | | | | 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-0/+26
| | | | | | | | | | | | | | | | | | | | 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
* [Support] Support building LLVM for FuchsiaPetr Hosek2018-05-031-0/+3
| | | | | | | | | | These are necessary changes to support building LLVM for Fuchsia. While these are not sufficient to run on Fuchsia, they are still useful when cross-compiling LLVM libraries and runtimes for Fuchsia. Differential Revision: https://reviews.llvm.org/D46345 llvm-svn: 331423
* Remove HAVE_DIRENT_H.Nico Weber2018-04-021-17/+2
| | | | | | | The autoconf manual: "This macro is obsolescent, as all current systems with directory libraries have <dirent.h>. New programs need not use this macro." llvm-svn: 328989
* [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
* Silence warning about unused private variable.Zachary Turner2018-02-151-1/+3
| | | | llvm-svn: 325275
* [Support] Use realpath(3) instead of trying to open a file.Davide Italiano2018-01-091-6/+6
| | | | | | | | | If we don't have read permissions on the directory the call would fail. <rdar://problem/35871293> llvm-svn: 322095
* [Support/UNIX] posix_fallocate() can fail with EINVAL.Davide Italiano2017-11-071-1/+1
| | | | | | | | | | | | | | | | | According to the docs on opegroup.org, the function can return EINVAL if: The len argument is less than zero, or the offset argument is less than zero, or the underlying file system does not support this operation. I'd say it's a peculiar choice (when EONOTSUPP is right there), but let's keep POSIX happy for now. This was independently discovered by Mark Millard (on FreeBSD/ZFS). Quickly ack'ed by Rui on IRC. llvm-svn: 317535
* Support: Have directory_iterator::status() return ↵Peter Collingbourne2017-10-101-7/+13
| | | | | | | | | | | | | | | | | | 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] mapped_file_region::size() returns size_tRoman Lebedev2017-09-271-1/+1
| | | | | | Fixup last commit, found by clang-stage1-cmake-RA-incremental bot. llvm-svn: 314313
* [Support] mapped_file_region: store size as size_tRoman Lebedev2017-09-271-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Found when testing stage-2 build with D38101. ``` In file included from /build/llvm/lib/Support/Path.cpp:1045: /build/llvm/lib/Support/Unix/Path.inc:648:14: error: comparison 'uint64_t' (aka 'unsigned long') > 18446744073709551615 is always false [-Werror,-Wtautological-constant-compare] if (length > std::numeric_limits<size_t>::max()) { ~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ``` `size_t` is `uint64_t` here, apparently, thus any `uint64_t` value always fits into `size_t`. Initial patch was to use some preprocessor logic to not check if the size is known to fit at compile time. But Zachary Turner suggested using this approach. Reviewers: Bigcheese, rafael, zturner, mehdi_amini Reviewed by (via email): zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38132 llvm-svn: 314312
* [Support] Remove getPathFromOpenFD, it was unusedReid Kleckner2017-08-041-47/+0
| | | | | | | | | | | | | | Summary: It was added to support clang warnings about includes with case mismatches, but it ended up not being necessary. Reviewers: twoh, rafael Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D36328 llvm-svn: 310078
* Remove Bitrig: LLVM ChangesErich Keane2017-07-211-7/+6
| | | | | | | | Bitrig code has been merged back to OpenBSD, thus the OS has been abandoned. Differential Revision: https://reviews.llvm.org/D35707 llvm-svn: 308799
* Recommit "[Support] Add RetryAfterSignal helper function"Pavel Labath2017-06-291-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | The difference from the previous version is the use of decltype, as the implementation of std::result_of in libc++ did not work correctly for variadic function like open(2). Original summary: This function retries an operation if it was interrupted by a signal (failed with EINTR). It's inspired by the TEMP_FAILURE_RETRY macro in glibc, but I've turned that into a template function. I've also added a fail-value argument, to enable the function to be used with e.g. fopen(3), which is documented to fail for any reason that open(2) can fail (which includes EINTR). The main user of this function will be lldb, but there were also a couple of uses within llvm that I could simplify using this function. Reviewers: zturner, silvas, joerg Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D33895 llvm-svn: 306671
* Revert "[Support] Add RetryAfterSignal helper function" and subsequent fixPavel Labath2017-06-221-4/+8
| | | | | | | | | | | The fix in r306003 uncovered a pretty fundamental problem that libc++ implementation of std::result_of does not handle the prototype of open(2) correctly (presumably because it contains ...). This makes the whole function unusable in its current form, so I am also reverting the original commit (r305892), which introduced the function, at least until I figure out a way to solve the libc++ issue. llvm-svn: 306005
* [Support] Add RetryAfterSignal helper functionPavel Labath2017-06-211-8/+4
| | | | | | | | | | | | | | | | | | | | | Summary: This function retries an operation if it was interrupted by a signal (failed with EINTR). It's inspired by the TEMP_FAILURE_RETRY macro in glibc, but I've turned that into a template function. I've also added a fail-value argument, to enable the function to be used with e.g. fopen(3), which is documented to fail for any reason that open(2) can fail (which includes EINTR). The main user of this function will be lldb, but there were also a couple of uses within llvm that I could simplify using this function. Reviewers: zturner, silvas, joerg Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D33895 llvm-svn: 305892
* 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
* [Solaris] Fix PR33228 - llvm::sys::fs::is_local_impl done rightKamil Rytarowski2017-06-011-0/+5
| | | | | | | | | | | | | | | | | | Summary: Solaris-specific implementation for llvm::sys::fs::is_local_impl. FStype pattern matching might be a bit unreliable, but at least it fixes the build failure. Reviewers: mgorny, nlopes, llvm-commits, krytarowski Reviewed By: krytarowski Subscribers: voskresensky.vladimir, krytarowski Differential Revision: https://reviews.llvm.org/D33695 llvm-svn: 304412
* Revert r303015, because it has the unintended side effect of breakingDimitry Andric2017-05-171-24/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | driver-mode recognition in clang (this is because the sysctl method always returns one and only one executable path, even for an executable with multiple links): Fix DynamicLibraryTest.cpp on FreeBSD and NetBSD Summary: After rL301562, on FreeBSD the DynamicLibrary unittests fail, because the test uses getMainExecutable("DynamicLibraryTests", Ptr), and since the path does not contain any slashes, retrieving the main executable will not work. Reimplement getMainExecutable() for FreeBSD and NetBSD using sysctl(3), which is more reliable than fiddling with relative or absolute paths. Also add retrieval of the original argv[] from the GoogleTest framework, to use as a fallback for other OSes. Reviewers: emaste, marsupial, hans, krytarowski Reviewed By: krytarowski Subscribers: krytarowski, llvm-commits Differential Revision: https://reviews.llvm.org/D33171 llvm-svn: 303285
* Fix DynamicLibraryTest.cpp on FreeBSD and NetBSDDimitry Andric2017-05-141-6/+24
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: After rL301562, on FreeBSD the DynamicLibrary unittests fail, because the test uses getMainExecutable("DynamicLibraryTests", Ptr), and since the path does not contain any slashes, retrieving the main executable will not work. Reimplement getMainExecutable() for FreeBSD and NetBSD using sysctl(3), which is more reliable than fiddling with relative or absolute paths. Also add retrieval of the original argv[] from the GoogleTest framework, to use as a fallback for other OSes. Reviewers: emaste, marsupial, hans, krytarowski Reviewed By: krytarowski Subscribers: krytarowski, llvm-commits Differential Revision: https://reviews.llvm.org/D33171 llvm-svn: 303015
OpenPOWER on IntegriCloud