summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Path.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Initial implementation of -fmacro-prefix-map and -ffile-prefix-mapDan McGregor2019-11-261-9/+32
| | | | | | | | | GCC 8 implements -fmacro-prefix-map. Like -fdebug-prefix-map, it replaces a string prefix for the __FILE__ macro. -ffile-prefix-map is the union of -fdebug-prefix-map and -fmacro-prefix-map Reviewed By: rnk, Lekensteyn, maskray Differential Revision: https://reviews.llvm.org/D49466
* [Path] Fix bug in make_absolute logicJonas Devlieghere2019-08-061-3/+3
| | | | | | | | | | | This fixes a bug for making path with a //net style root absolute. I discovered the bug while writing a test case for the VFS, which uses these paths because they're both legal absolute paths on Windows and Unix. Differential revision: https://reviews.llvm.org/D65675 llvm-svn: 368053
* [Path] Set FD to -1 in moved-from TempFileJonas Devlieghere2019-06-111-0/+1
| | | | | | | | | When moving a temp file, explicitly set the file descriptor to -1 so we can never accidentally close the moved-from TempFile. Differential revision: https://reviews.llvm.org/D63087 llvm-svn: 363083
* Assigning to a local object in a return statement prevents copy elision. NFC.David Blaikie2019-04-251-1/+2
| | | | | | | | | | | | | | | | I added a diagnostic along the lines of `-Wpessimizing-move` to detect `return x = y` suppressing copy elision, but I don't know if the diagnostic is really worth it. Anyway, here are the places where my diagnostic reported that copy elision would have been possible if not for the assignment. P1155R1 in the post-San-Diego WG21 (C++ committee) mailing discusses whether WG21 should fix this pitfall by just changing the core language to permit copy elision in cases like these. (Kona update: The bulk of P1155 is proceeding to CWG review, but specifically *not* the parts that explored the notion of permitting copy-elision in these specific cases.) Reviewed By: dblaikie Author: Arthur O'Dwyer Differential Revision: https://reviews.llvm.org/D54885 llvm-svn: 359236
* Revert using fcopyfile(3) to implement sys::fs::copy_file(Twine, int) on macOSAdrian Prantl2019-04-241-2/+2
| | | | | | | | | 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/+2
| | | | | | | | | | | | | | | | | | 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-2/+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/+2
| | | | | | | | | | | | | | | 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
* [llvm-objcopy] Make .build-id linking atomicJake Ehrlich2019-03-181-26/+27
| | | | | | | | This change makes linking into .build-id atomic and safe to use. Some users under particular workflows are reporting that this races more than half the time under particular conditions. llvm-svn: 356404
* [Support] Fix TempFile::discard to not leave behind temporary filesAndrew Ng2019-02-141-13/+14
| | | | | | | | | | | | | | Moved the remove of the temporary file to after the close to avoid remove failures caused by ETXTBSY errors. This issue was seen when FileOutputBuffer falls back to an in memory buffer due to the inability to mmap the on disk file. This occurred when running LLD on an Ubuntu VM in VirtualBox on a Windows host attempting to write the output to a VirtualBox shared folder. Differential Revision: https://reviews.llvm.org/D57960 llvm-svn: 354017
* 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] Remove error return value from one overload of fs::make_absolutePavel Labath2019-01-161-17/+16
| | | | | | | | | | | | | | | | | | | | | | Summary: The version of make_absolute which accepted a specific directory to use as the "base" for the computation could never fail, even though it returned a std::error_code. The reason for that seems to be historical -- the CWD flavour (which can fail due to failure to retrieve CWD) was there first, and the new version was implemented by extending that. This removes the error return value from the non-CWD overload and reimplements the CWD version on top of that. This enables us to remove some dead code where people were pessimistically trying to handle the errors returned from this function. Reviewers: zturner, sammccall Subscribers: hiraditya, kristina, llvm-commits Differential Revision: https://reviews.llvm.org/D56599 llvm-svn: 351317
* Use llvm::copy. NFCFangrui Song2018-11-171-1/+1
| | | | llvm-svn: 347126
* Remove dead function user_cache_directory()Nico Weber2018-09-181-12/+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-6/+7
| | | | | | | | | | | | | | | | 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
* [Windows FS] Allow moving files in TempFile::keepJeremy Morse2018-08-031-1/+9
| | | | | | | | | | | | In r338216 / D49860 TempFile::keep was extended to allow keeping across filesystems. The aim on Windows was to have this happen in rename_internal using the existing system API. However, to fix an issue and preserve the idea of "renaming" not being a move, put Windows keep-across-filesystem in TempFile::keep. Differential Revision: https://reviews.llvm.org/D50048 llvm-svn: 338841
* [Support] [NFC] change comment about retries in createUniqueEntityBob Haarman2018-08-021-2/+4
| | | | | | Rewording as requested on D50126 after the change was pushed. llvm-svn: 338755
* [Support] fix TempFile infinite loop and permission denied errorsBob Haarman2018-08-021-35/+42
| | | | | | | | | | | | | | | | | | | | Summary: On Windows, TempFile::create() was prone to failing with permission denied errors when a process created many tempfiles without providing a model large enough to accommodate them. There was also a problem with createUniqueEntity getting into an infinite loop when all names permitted by the model are in use. This change fixes both of these problems and adds a unit test for them. Reviewers: pcc, rnk, zturner Reviewed By: zturner Subscribers: inglorion, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D50126 llvm-svn: 338745
* [dsymutil] Simplify temporary file handling.Jonas Devlieghere2018-07-291-3/+7
| | | | | | | | | | | Dsymutil's update functionality was broken on Windows because we tried to rename a file while we're holding open handles to that file. TempFile provides a solution for this through its keep(Twine) method. This patch changes dsymutil to make use of that functionality. Differential revision: https://reviews.llvm.org/D49860 llvm-svn: 338216
* Fix typo in lib/Support/Path.cpp to test commit accessVladimir Stefanovic2018-07-031-1/+1
| | | | llvm-svn: 336216
* Add a flag to FileOutputBuffer that allows modification.Zachary Turner2018-06-281-12/+31
| | | | | | | | | | | | | FileOutputBuffer creates a temp file and on commit atomically renames the temp file to the destination file. Sometimes we want to modify an existing file in place, but still have the atomicity guarantee. To do this we can initialize the contents of the temp file from the destination file (if it exists), that way the resulting FileOutputBuffer can have only selective bytes modified. Committing will then atomically replace the destination file as desired. llvm-svn: 335902
* LTO: Keep file handles open for memory mapped files.Peter Collingbourne2018-06-131-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [FileSystem] Split up the OpenFlags enumeration.Zachary Turner2018-06-071-7/+8
| | | | | | | | | | | | | | | | | 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
* [FileSystem] Remove OpenFlags param from several functions.Zachary Turner2018-06-051-14/+16
| | | | | | | | | | | | There was only one place in the entire codebase where a non default value was being passed, and that place was already hidden in an implementation file. So we can delete the extra parameter and all existing clients continue to work as they always have, while making the interface a bit simpler. Differential Revision: https://reviews.llvm.org/D47789 llvm-svn: 334046
* Revert 332508 as it caused problems in the clang test suite.Greg Clayton2018-05-161-4/+0
| | | | llvm-svn: 332555
* Fix llvm::sys::path::remove_dots() to return "." instead of an empty path.Greg Clayton2018-05-161-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D46887 llvm-svn: 332508
* [Support/Path] Make handling of paths like "///" consistentPavel Labath2018-05-091-24/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Various path functions were not treating paths consisting of slashes alone consistently. For example, the iterator-based accessors decomposed the path "///" into two elements: "/" and ".". This is not too bad, but it is different from the behavior specified by posix: ``` A pathname that contains ***at least one non-slash character*** and that ends with one or more trailing slashes shall be resolved as if a single dot character ( '.' ) were appended to the pathname. ``` More importantly, this was different from how we treated the same path in the filename+parent_path functions, which decomposed this path into "." and "". This was completely wrong as it lost the information that this was an absolute path which referred to the root directory. This patch fixes this behavior by making sure all functions treat paths consisting of (back)slashes alone the same way as "/". I.e., the iterator-based functions will just report one component ("/"), and the filename+parent_path will decompose them into "/" and "". A slightly controversial topic here may be the treatment of "//". Posix says that paths beginning with "//" may have special meaning and indeed we have code which parses paths like "//net/foo/bar" specially. However, as we were already not being consistent in parsing the "//" string alone, and any special parsing for it would complicate the code further, I chose to treat it the same way as longer sequences of slashes (which are guaranteed to be the same as "/"). Another slight change of behavior is in the parsing of paths like "//net//". Previously the last component of this path was ".". However, as in our parsing the "//net" part in this path was the same as the "drive" part in "c:\" and the next slash was the "root directory", it made sense to treat "//net//" the same way as "//net/" (i.e., not to add the extra "." component at the end). Reviewers: zturner, rnk, dblaikie, Bigcheese Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45942 llvm-svn: 331876
* IWYU for llvm-config.h in llvm, additions.Nico Weber2018-04-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
* s/LLVM_ON_WIN32/_WIN32/, llvmNico Weber2018-04-291-6/+6
| | | | | | | | | | | | | | LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of a reinvented one. See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. No intended behavior change. This moves over all uses of the macro, but doesn't remove the definition of it in (llvm-)config.h yet. llvm-svn: 331127
* Changed createTemporaryFile without FD to actually create a file.Ilya Biryukov2018-03-191-7/+32
| | | | | | | | | | | | | | | | | | | | | Summary: This commit changes semantics of createUniqueFile and createTemporaryFile variants that do not return file descriptors. Previously they only checked if files exist, therefore being subject to race conditions. Now they will create an empty file to avoid them. Functions that do not create a file are now called getPotentiallyUniqueTempFileName and getPotentiallyUniqueFileName. Reviewers: klimek, bkramer, krasimir, JDevlieghere, espindola Reviewed By: klimek Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D36827 llvm-svn: 327851
* Delete temp file if rename fails.Rafael Espindola2017-12-051-0/+6
| | | | | | | | | | | | | | | | | | | Without this when lld failed to replace the output file it would leave the temporary behind. The problem is that the existing logic is - cancel the delete flag - rename We have to cancel first to avoid renaming and then crashing and deleting the old version. What is missing then is deleting the temporary file if the rename fails. This can be an issue on both unix and windows, but I am not sure how to cause the rename to fail reliably on unix. I think it can be done on ZFS since it has an ACL system similar to what windows uses, but adding support for checking that in llvm-lit is probably not worth it. llvm-svn: 319786
* Use FILE_FLAG_DELETE_ON_CLOSE for TempFile on windows.Rafael Espindola2017-11-281-3/+22
| | | | | | We won't see the temp file no more. llvm-svn: 319137
* Move code. NFC.Rafael Espindola2017-11-281-83/+85
| | | | | | | This moves the TempFile implementation so that it can use system specific code. llvm-svn: 319134
* Add OpenFlags to the create(Unique|Temporary)File interfaces.Rafael Espindola2017-11-271-14/+20
| | | | | | | This will allow a future F_Delete flag to be specified when we want the file to be automatically deleted on close. llvm-svn: 319117
* Allow TempFile::discard to be called twice.Rafael Espindola2017-11-221-0/+6
| | | | | | | | | | We already allowed keep+discard. It is important to be able to discard a temporary if a rename fail. It is also convenient as it allows the use of RAII for discarding. Allow discarding twice for similar reasons. llvm-svn: 318867
* Convert another use of createUniqueFile to TempFile::create.Rafael Espindola2017-11-161-0/+16
| | | | | | | This one requires a new small feature in TempFile: the ability to keep the temporary file with the temporary name. llvm-svn: 318458
* Use TempFile in lto caching.Rafael Espindola2017-11-151-5/+12
| | | | | | | | | | This requires a small change to TempFile: allowing a discard after a failed keep. With this the cache now handles signals and reuses a fd instead of reopening the file. llvm-svn: 318322
* Add a move assignment operator to TempFile. NFC.Rafael Espindola2017-11-141-1/+3
| | | | llvm-svn: 318122
* Create a TempFile class.Rafael Espindola2017-11-131-0/+53
| | | | | | | | | | | | | | | This just adds a TempFile class and replaces the use in FileOutputBuffer with it. The only difference for now is better error handling. Followup work includes: - Convert other user of temporary files to it. - Add support for automatically deleting on windows. - Add a createUnnamed method that returns a potentially unnamed file. It would be actually unnamed on modern linux and have a unknown name on windows. llvm-svn: 318069
* Support: Have directory_iterator::status() return ↵Peter Collingbourne2017-10-101-11/+8
| | | | | | | | | | | | | | | | | | 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
* [Path] Sink predicate computations to their uses. NFCI.Benjamin Kramer2017-08-091-5/+4
| | | | llvm-svn: 310531
* Support/Path.cpp: Prune unused "llvm/BinaryFormat".NAKAMURA Takumi2017-07-171-2/+0
| | | | llvm-svn: 308160
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-071-174/+2
| | | | | | | | | | | | This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
* Added LLVM_FALLTHROUGH to address gcc warning: this statement may fall through.Galina Kistanova2017-05-231-0/+1
| | | | llvm-svn: 303595
* Add a function to MD5 a file's contents.Zachary Turner2017-03-201-2/+33
| | | | | | | | | | | | | | | In doing so, clean up the MD5 interface a little. Most existing users only care about the lower 8 bytes of an MD5, but for some users that care about the upper and lower, there wasn't a good interface. Furthermore, consumers of the MD5 checksum were required to handle endianness details on their own, so it seems reasonable to abstract this into a nicer interface that just gives you the right value. Differential Revision: https://reviews.llvm.org/D31105 llvm-svn: 298322
* [Support] Support both Windows and Posix paths on both platforms.Zachary Turner2017-03-161-223/+202
| | | | | | | | | | | | | | | | | | Previously which path syntax we supported dependend on what platform we were compiling LLVM on. While this is normally desirable, there are situations where we need to be able to handle a path that we know was generated on a remote host. Remote debugging, for example, or parsing debug info. 99% of the code in LLVM for handling paths was platform agnostic and literally just a few branches were gated behind pre-processor checks, so this changes those sites to use runtime checks instead, and adds a flag to every path API that allows one to override the host native syntax. Differential Revision: https://reviews.llvm.org/D30858 llvm-svn: 298004
* [Support] Add support for getting file system permissions on Windows and ↵James Henderson2017-03-161-0/+8
| | | | | | | | | | | | | | | | | | 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-14/+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/+14
| | | | | | | | sys::fs::permissions to set them. Patch by James Henderson. llvm-svn: 297617
* [Support] Add llvm::sys::fs::remove_directories.Zachary Turner2017-03-081-1/+1
| | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud