summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Unix/Path.inc
Commit message (Collapse)AuthorAgeFilesLines
* 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
* If posix_fallocate returns EOPNOTSUPP, fallback to ftruncate.Joerg Sonnenberger2017-05-051-4/+5
| | | | | | This can happen at least on NetBSD. llvm-svn: 302263
* Make home_directory look in the password database in addition to $HOME.Zachary Turner2017-03-221-5/+11
| | | | | | | | | | | | | This is something of an edge case, but when the $HOME environment variable is not set, we can still look in the password database to get the current user's home directory. Added a test for this by getting the value of $HOME, then unsetting it, then calling home_directory() and verifying that it succeeds and that the value is the same as what we originally read from the environment. llvm-svn: 298513
* [Support] Fill the file_status struct with link count.Zachary Turner2017-03-201-4/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D31110 llvm-svn: 298326
* Fix linux build.Zachary Turner2017-03-161-1/+2
| | | | llvm-svn: 298007
* [Support] Add support for getting file system permissions on Windows and ↵James Henderson2017-03-161-1/+10
| | | | | | | | | | | | | | | | | | implement sys::fs::set/getPermissions to work with them This change adds support for functions to set and get file permissions, in a similar manner to the C++17 permissions() function in <filesystem>. The setter uses chmod on Unix systems and SetFileAttributes on Windows, setting the permissions as passed in. The getter simply uses the existing status() function. Prior to this change, status() would always return an unknown value for the permissions on a Windows file, making it impossible to test the new function on Windows. I have therefore added support for this as well. On Linux, prior to this change, the permissions included the file type, which should actually be accessed via a different member of the file_status class. Note that on Windows, only the *_write permission bits have any affect - if any are set, the file is writable, and if not, the file is read-only. This is in common with what MSDN describes for their behaviour of std::filesystem::permissions(), and also what boost::filesystem does. The motivation behind this change is so that we can easily test behaviour on read-only files in LLVM unit tests, but I am sure that others may find it useful in some situations. Reviewers: zturner, amccarth, aaron.ballman Differential Revision: https://reviews.llvm.org/D30736 llvm-svn: 297945
* Reverting r297617 because it broke some bots:Aaron Ballman2017-03-131-15/+6
| | | | | | http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/49970 llvm-svn: 297618
* Add support for getting file system permissions and implement ↵Aaron Ballman2017-03-131-6/+15
| | | | | | | | sys::fs::permissions to set them. Patch by James Henderson. llvm-svn: 297617
* Add llvm::sys::fs::real_path.Zachary Turner2017-03-101-1/+63
| | | | | | | | | | | | | | | | | | | | | LLVM already has real_path like functionality, but it is cumbersome to use and involves clean up after (e.g. you have to call openFileForRead, then close the resulting FD). Furthermore, on Windows it doesn't work for directories since opening a directory and opening a file require slightly different flags. So I add a simple function `real_path` which works for all paths on all platforms and has a simple to use interface. In doing so, I add the ability to opt in to resolving tilde expressions (e.g. ~/foo), which are normally handled by the shell. Differential Revision: https://reviews.llvm.org/D30668 llvm-svn: 297483
* fix build on CygwinNuno Lopes2017-03-091-0/+3
| | | | llvm-svn: 297378
* [Support] Add llvm::sys::fs::remove_directories.Zachary Turner2017-03-081-2/+43
| | | | | | | | | | | | | | | | | | | | | We already have a function create_directories() which can create an entire tree, and remove() which can remove an empty directory, but we do not have remove_directories() which can remove an entire tree. This patch adds such a function. Because removing a directory tree can have dangerous consequences when the tree contains a directory symlink, the patch here updates the existing directory_iterator construct to optionally not follow symlinks (previously it would always follow symlinks). The delete algorithm uses this flag so that for symlinks, only the links are removed, and not the targets. On Windows this is implemented with SHFileOperation, which also does not recurse into symbolic links or junctions. Differential Revision: https://reviews.llvm.org/D30676 llvm-svn: 297314
* [fs] Make sure to check S_ISLNK() in fillStatus.Zachary Turner2017-03-071-0/+2
| | | | llvm-svn: 297167
* [Support] Add the option to not follow symlinks on stat.Zachary Turner2017-03-071-2/+2
| | | | llvm-svn: 297154
OpenPOWER on IntegriCloud