Commit Graph

41 Commits

Author SHA1 Message Date
Ben Langmuir 450461cb76 Reapply "Use gethostuuid() on Mac to identify hosts for LockFileManager"
Reapplies r241005 after fixing the build on non-Mac platforms. Original
commit message below.

The hostname can be very unstable when there are many machines on the
network competing for the same name. Using the hardware UUID makes it
less likely to have collisions or to consider files written by the
current host to be owned by a different one at a later time.

rdar://problem/21512307

llvm-svn: 241012
2015-06-29 22:16:39 +00:00
Ben Langmuir 5123eecd63 Revert "Use gethostuuid() on Mac to identify hosts for LockFileManager"
Broke non-Mac builds.

This reverts commit r241005.

llvm-svn: 241007
2015-06-29 21:56:03 +00:00
Ben Langmuir c349cf3939 Use gethostuuid() on Mac to identify hosts for LockFileManager
The hostname can be very unstable when there are many machines on the
network competing for the same name. Using the hardware UUID makes it
less likely to have collisions or to consider files written by the
current host to be owned by a different one at a later time.

rdar://problem/21512307

llvm-svn: 241005
2015-06-29 21:47:44 +00:00
Ben Langmuir 63aa8c5d28 Clean up unique lock files on signal and always release the lock
Make sure to remove the unique lock file, which is what the .lock
symlink points to, if there is a signal while the lock is held. This
will release the lock, since the symlink will point to nothing (already
tested in unit tests). For good measure, also clean up the unique lock
file if there is an error or signal before the lock is acquired.

I will add a clang test.

rdar://problem/21512307

llvm-svn: 240967
2015-06-29 17:08:41 +00:00
Benjamin Kramer 16132e6faa Purge unused includes throughout libSupport.
NFC.

llvm-svn: 232976
2015-03-23 18:07:13 +00:00
Yaron Keren 92e1b62d45 Remove many superfluous SmallString::str() calls.
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
2015-03-18 10:17:07 +00:00
Argyrios Kyrtzidis dc8f979b41 [Support] Increase timeout for the LockFileManager back to 5 mins.
Waiting for just 1 min may not be enough for some contexts.

llvm-svn: 231309
2015-03-04 22:54:38 +00:00
Ben Langmuir 0897091730 Assume the original file is created before release in LockFileManager
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
2015-02-19 18:22:35 +00:00
Ben Langmuir d2d52de229 Reduce the LockFileManager timeout, and provide unsafeRemoveLockFile
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
2015-02-09 20:34:24 +00:00
Rafael Espindola 281f23adc1 Misc cleanups to the FileSytem api.
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
2014-09-11 20:30:02 +00:00
Rafael Espindola 3f6481d0d3 Remove some calls to std::move.
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
2014-08-01 14:31:55 +00:00
Rafael Espindola adf21f2a56 Update the MemoryBuffer API to use ErrorOr.
llvm-svn: 212405
2014-07-06 17:43:13 +00:00
Rafael Espindola 2a826e40fa Finishing touch for the std::error_code transition.
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
2014-06-13 17:20:48 +00:00
Rafael Espindola db4ed0bdab Remove 'using std::errro_code' from lib.
llvm-svn: 210871
2014-06-13 02:24:39 +00:00
Rafael Espindola 3acea39853 Don't use 'using std::error_code' in include/llvm.
This should make sure that most new uses use the std prefix.

llvm-svn: 210835
2014-06-12 21:46:39 +00:00
Rafael Espindola ed6882b835 Don't import make_error_code into the llvm namespace.
llvm-svn: 210772
2014-06-12 11:58:49 +00:00
Rafael Espindola 5c4f829424 Use std::error_code instead of llvm::error_code.
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
2014-06-11 19:05:50 +00:00
Rafael Espindola a3f2e3f01e There is no std::errc::success, remove the llvm one.
llvm-svn: 209960
2014-05-31 03:21:04 +00:00
Craig Topper c10719f55d [C++11] Make use of 'nullptr' in the Support library.
llvm-svn: 205697
2014-04-07 04:17:22 +00:00
Argyrios Kyrtzidis 44ec0a7d76 [Support] Modify LockFileManager::waitForUnlock() to return info about how the lock was released.
llvm-svn: 205683
2014-04-06 03:19:31 +00:00
Argyrios Kyrtzidis 900e9a3da0 [Support] Follow up to r204426, for LockFileManager, make the given path absolute so relative paths are properly handled in both Windows and Unix.
llvm-svn: 204520
2014-03-21 21:45:07 +00:00
Argyrios Kyrtzidis 531a5be4d0 [Support] Make sure LockFileManager works correctly with relative paths.
llvm-svn: 204426
2014-03-21 02:31:56 +00:00
Argyrios Kyrtzidis 3757569318 [Support] Make sure sys::fs::remove can remove symbolic links and make sure LockFileManager can handle a symbolic link that points nowhere.
llvm-svn: 204422
2014-03-21 01:25:37 +00:00
Rafael Espindola 83f858e578 Cleanup the interface for creating soft or hard links.
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
2014-03-11 18:40:24 +00:00
Argyrios Kyrtzidis 4147978cc5 [Support/LockFileManager] Re-apply r203137 and r203138 but use symbolic links only on unix.
Reid Kleckner pointed out that we can't use symbolic links on Windows.

llvm-svn: 203162
2014-03-06 20:53:58 +00:00