Windows normally limits the length of an absolute path name to 260
characters; directories can have lower limits. These limits increase
to about 32K if you use absolute paths with the special '\\?\'
prefix. Teach Support\Windows\Path.inc to use that prefix as needed.
TODO: Other parts of Support could also learn to use this prefix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221841 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217625 91177308-0d34-0410-b5e6-96231b3b80d8
Take a StringRef instead of a "const char *".
Take a "std::error_code &" instead of a "std::string &" for error.
A create static method would be even better, but this patch is already a bit too
big.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216393 91177308-0d34-0410-b5e6-96231b3b80d8
path::const_iterator claims that it's a bidirectional iterator, but it
doesn't satisfy all of the contracts for a bidirectional iterator.
For example, n3376 24.2.5 p6 says "If a and b are both dereferenceable,
then a == b if and only if *a and *b are bound to the same object",
but this doesn't work with how we stash and recreate Components.
This means that our use of reverse_iterator on this type is invalid
and leads to many of the valgrind errors we're hitting, as explained
by Tilmann Scheller here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140728/228654.html
Instead, we admit that path::const_iterator is only an input_iterator,
and implement a second input_iterator for path::reverse_iterator (by
changing const_iterator::operator-- to reverse_iterator::operator++).
All of the uses of this just traverse once over the path in one
direction or the other anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214737 91177308-0d34-0410-b5e6-96231b3b80d8
This re-enables some #if 0'd code (since 2010) in the Path unittests
and makes at least a weak effort at testing sys::path's rbegin/rend.
This change was inspired by some test failures near uses of rbegin and
rend here:
http://lab.llvm.org:8011/builders/clang-x86_64-linux-vg/builds/3209
The "valgrind was whining" comment looked promising in terms of a
simpler to debug case of the same errors. However, it appears that the
valgrind complaints the comment was referring to are distinct from the
ones in the frontend, since this updated test isn't complaining for me
under valgrind.
In any case, the disabled tests weren't helping anybody.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213125 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210920 91177308-0d34-0410-b5e6-96231b3b80d8
This will allow inlining get_magic, which should in turn fix one of the mingw
build problems after the switch to std::error_code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210712 91177308-0d34-0410-b5e6-96231b3b80d8
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++.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210687 91177308-0d34-0410-b5e6-96231b3b80d8
MSVC doesn't seem to provide any is_error_code_enum enumeration for the
windows errors.
Fortunately very few places in llvm have to handle raw windows errors, so
we can just construct the corresponding error_code directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210631 91177308-0d34-0410-b5e6-96231b3b80d8
Add a utility function to convert the Windows path separator to Unix style path
separators. This is used by a subsequent change in clang to enable the use of
Windows SDK headers on Linux.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203611 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203596 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203083 91177308-0d34-0410-b5e6-96231b3b80d8
When using a //net/ path, we were transforming the trailing / into a '.'
when the path was just the root path and we were iterating backwards.
Forwards iteration and other kinds of root path (C:\, /) were already
correct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202999 91177308-0d34-0410-b5e6-96231b3b80d8
After this I will set the default back to F_None. The advantage is that
before this patch forgetting to set F_Binary would corrupt a file on windows.
Forgetting to set F_Text produces one that cannot be read in notepad, which
is a better failure mode :-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202052 91177308-0d34-0410-b5e6-96231b3b80d8
Before this patch they would take an boolean argument to say if the path
already existed. This was redundant with the returned error_code which is able
to represent that. This allowed for callers to incorrectly check only the
existed flag instead of first checking the error code.
Instead, pass in a boolean flag to say if the previous (non-)existence should be
an error or not.
Callers of the of the old simple versions are not affected. They still ignore
the previous (non-)existence as they did before.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201979 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Some machine-type-neutral object files containing only undefined symbols
actually do exist in the Windows standard library. Need to recognize them
as COFF files.
Reviewers: Bigcheese
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2164
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194734 91177308-0d34-0410-b5e6-96231b3b80d8
The unix one was returning no_such_file_or_directory, but the windows one
was return success.
Update the one one caller that was depending on the old behavior.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187463 91177308-0d34-0410-b5e6-96231b3b80d8
This centralizes the handling of O_BINARY and opens the way for hiding more
differences (like how open behaves with directories).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186447 91177308-0d34-0410-b5e6-96231b3b80d8
