summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/LockFileManager.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Purge unused includes throughout libSupport.Benjamin Kramer2015-03-231-2/+0
| | | | | | NFC. llvm-svn: 232976
* Remove many superfluous SmallString::str() calls.Yaron Keren2015-03-181-10/+10
| | | | | | | | | | | | | | | Now that SmallString is a first-class citizen, most SmallString::str() calls are not required. This patch removes a whole bunch of them, yet there are lots more. There are two use cases where str() is really needed: 1) To use one of StringRef member functions which is not available in SmallString. 2) To convert to std::string, as StringRef implicitly converts while SmallString do not. We may wish to change this, but it may introduce ambiguity. llvm-svn: 232622
* [Support] Increase timeout for the LockFileManager back to 5 mins.Argyrios Kyrtzidis2015-03-041-2/+3
| | | | | | Waiting for just 1 min may not be enough for some contexts. llvm-svn: 231309
* Assume the original file is created before release in LockFileManagerBen Langmuir2015-02-191-39/+9
| | | | | | | | | | This is true in clang, and let's us remove the problematic code that waits around for the original file and then times out if it doesn't get created in short order. This caused any 'dead' lock file or legitimate time out to cause a cascade of timeouts in any processes waiting on the same lock (even if they only just showed up). llvm-svn: 229881
* Reduce the LockFileManager timeout, and provide unsafeRemoveLockFileBen Langmuir2015-02-091-2/+6
| | | | | | | | | | 5 minutes is an eternity, so try to strike a better balance between waiting long enough for any reasonable module build and not so long that users kill the process because they think it's hanging. Also give the client a way to delete the lock file after a timeout. llvm-svn: 228603
* Misc cleanups to the FileSytem api.Rafael Espindola2014-09-111-2/+2
| | | | | | | | | | | | | | | | The main difference is the removal of std::error_code exists(const Twine &path, bool &result); It was an horribly redundant interface since a file not existing is also a valid error_code. Now we have an access function that returns just an error_code. This is the only function that has to be implemented for Unix and Windows. The functions can_write, exists and can_execute an now just wrappers. One still has to be very careful using these function to avoid introducing race conditions (Time of check to time of use). llvm-svn: 217625
* Remove some calls to std::move.Rafael Espindola2014-08-011-2/+2
| | | | | | | | | Instead of moving out the data in a ErrorOr<std::unique_ptr<Foo>>, get a reference to it. Thanks to David Blaikie for the suggestion. llvm-svn: 214516
* Update the MemoryBuffer API to use ErrorOr.Rafael Espindola2014-07-061-2/+4
| | | | llvm-svn: 212405
* Finishing touch for the std::error_code transition.Rafael Espindola2014-06-131-2/+3
| | | | | | | | | | | While std::error_code itself seems to work OK in all platforms, there are few annoying differences with regards to the std::errc enumeration. This patch adds a simple llvm enumeration, which will hopefully avoid build breakages in other platforms and surprises as we get more uses of std::error_code. llvm-svn: 210920
* Remove 'using std::errro_code' from lib.Rafael Espindola2014-06-131-7/+4
| | | | 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
* Don't import make_error_code into the llvm namespace.Rafael Espindola2014-06-121-1/+1
| | | | llvm-svn: 210772
* Use std::error_code instead of llvm::error_code.Rafael Espindola2014-06-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The idea of this patch is to turn llvm/Support/system_error.h into a transitional header that just brings in the erorr_code api to the llvm namespace. I will remove it shortly afterwards. The cases where the general idea needed some tweaking: * std::errc is a namespace in msvc, so we cannot use "using std::errc". I could add an #ifdef, but there were not that many uses, so I just added std:: to them in this patch. * Template specialization had to be moved to the std namespace in this patch set already. * The msvc implementation of default_error_condition doesn't seem to provide the same transformations as we need. Not too surprising since the standard doesn't actually say what "equivalent" means. I fixed the problem by keeping our old mapping and using it at error_code construction time. Despite these shortcomings I think this is still a good thing. Some reasons: * The different implementations of system_error might improve over time. * It removes 925 lines of code from llvm already. * It removes 6313 bytes from the text segment of the clang binary when it is built with gcc and 2816 bytes when building with clang and libstdc++. llvm-svn: 210687
* There is no std::errc::success, remove the llvm one.Rafael Espindola2014-05-311-1/+1
| | | | llvm-svn: 209960
* [C++11] Make use of 'nullptr' in the Support library.Craig Topper2014-04-071-1/+1
| | | | llvm-svn: 205697
* [Support] Modify LockFileManager::waitForUnlock() to return info about how ↵Argyrios Kyrtzidis2014-04-061-6/+10
| | | | | | the lock was released. llvm-svn: 205683
* [Support] Follow up to r204426, for LockFileManager, make the given path ↵Argyrios Kyrtzidis2014-03-211-3/+6
| | | | | | absolute so relative paths are properly handled in both Windows and Unix. llvm-svn: 204520
* [Support] Make sure LockFileManager works correctly with relative paths.Argyrios Kyrtzidis2014-03-211-1/+3
| | | | llvm-svn: 204426
* [Support] Make sure sys::fs::remove can remove symbolic links and make sure ↵Argyrios Kyrtzidis2014-03-211-6/+3
| | | | | | LockFileManager can handle a symbolic link that points nowhere. llvm-svn: 204422
* Cleanup the interface for creating soft or hard links.Rafael Espindola2014-03-111-30/+3
| | | | | | | | | | | | Before this patch the unix code for creating hardlinks was unused. The code for creating symbolic links was implemented in lib/Support/LockFileManager.cpp and the code for creating hard links in lib/Support/*/Path.inc. The only use we have for these is in LockFileManager.cpp and it can use both soft and hard links. Just have a create_link function that creates one or the other depending on the platform. llvm-svn: 203596
* [Support/LockFileManager] Re-apply r203137 and r203138 but use symbolic ↵Argyrios Kyrtzidis2014-03-061-24/+56
| | | | | | | | links only on unix. Reid Kleckner pointed out that we can't use symbolic links on Windows. llvm-svn: 203162
* Revert create_symbolic_link and both depending changesReid Kleckner2014-03-061-32/+24
| | | | | | | | | | This reverts commits r203136, r203137, and r203138. This code doesn't build on Windows. Even on Vista+, Windows requires elevated privileges to create a symlink. Therefore we can't use symlinks in the compiler. We'll have to find another approach. llvm-svn: 203143
* [Support/LockFileManager] Make the LockFileManager more robust against races.Argyrios Kyrtzidis2014-03-061-17/+34
| | | | | | | | | | | There was a race where: - The LockFileManager tries to own the lock file and fails. - The other owner then releases and removes the lock file. - The LockFileManager tries to read the owner info from the lock file but fails now. In such a case have LockFileManager try to get ownership again, instead of error'ing out. llvm-svn: 203138
* [Support/LockFileManager] Use symbolic link for the lock file.Argyrios Kyrtzidis2014-03-061-13/+4
| | | | | | | | Hard links do not work on SMB network directories, and it causes us to fail to build clang module files if the module cache is in such a directory. rdar://15944959 llvm-svn: 203137
* Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles2014-03-061-1/+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
* [C++11] Replace llvm::tie with std::tie.Benjamin Kramer2014-03-021-1/+1
| | | | | | The old implementation is no longer needed in C++11. llvm-svn: 202644
* Use simpler version of sys::fs::exists when possible.Rafael Espindola2014-02-131-5/+3
| | | | llvm-svn: 201289
* Use the simpler version of sys::fs::remove when possible.Rafael Espindola2014-01-101-8/+5
| | | | llvm-svn: 198958
* Fix boolean logic in LockFileManager and test itReid Kleckner2013-08-071-8/+10
| | | | | | | | | | This fixes a bug from r187826. Reviewers: hans Differential Revision: http://llvm-reviews.chandlerc.com/D1304 llvm-svn: 187846
* Remove some std stream usage from Support and TableGenReid Kleckner2013-08-061-9/+13
| | | | | | | | | | LLVM's coding standards recommend raw_ostream and MemoryBuffer for reading and writing text. This has the side effect of allowing clang to compile more of Support and TableGen in the Microsoft C++ ABI. llvm-svn: 187826
* Add a createUniqueFile function and switch llvm's users of unique_file.Rafael Espindola2013-07-051-4/+3
| | | | | | | | | | | | | | This function is complementary to createTemporaryFile. It handles the case were the unique file is *not* temporary: we will rename it in the end. Since we will rename it, the file has to be in the same filesystem as the final destination and we don't prepend the system temporary directory. This has a small semantic difference from unique_file: the default mode is 0666. This matches the behavior of most unix tools. For example, with this change lld now produces files with the same permissions as ld. I will add a test of this change when I port clang over to createUniqueFile (next commit). llvm-svn: 185726
* <rdar://problem/13551789> Fix a race in the LockFileManager.Douglas Gregor2013-04-051-5/+32
| | | | | | | | It's possible for the lock file to disappear and the owning process to return before we're able to see the generated file. Spin for a little while to see if it shows up before failing. llvm-svn: 178909
* Provide a "None" value for convenience when using Optional<T>()David Blaikie2013-02-211-2/+2
| | | | | | | This implementation of NoneType/None does have some holes but I haven't found one that doesn't - open to improvement. llvm-svn: 175696
* Fix a race condition in the lock-file manager: once the lock file isDouglas Gregor2013-01-101-3/+13
| | | | | | gone, check for the actual file we care about. llvm-svn: 172033
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-1/+1
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* Fix Android build of gtest and lib/Support.Evgeniy Stepanov2012-09-041-1/+1
| | | | llvm-svn: 163131
* Move Clang's file-level locking facility over to LLVM's supportDouglas Gregor2012-01-291-0/+216
library, since it doesn't really have anything to do with Clang. llvm-svn: 149203
OpenPOWER on IntegriCloud