Support: Remove sys::path::is_style_native()

Remove sys::path::is_style_native(), which was added alongside
is_style_windows() and is_style_posix().

Thinking a bit about the windows forward-slash s

Support: Remove sys::path::is_style_native()

Remove sys::path::is_style_native(), which was added alongside
is_style_windows() and is_style_posix().

Thinking a bit about the windows forward-slash style variant in
https://reviews.llvm.org/D111879, it's not clear to me how the new
sys::path::is_style_native() should behave for them.

- Should it return true for both `windows_slash` and
`windows_backslash`?
- Should it return true for only one of them?

I can think of hypothetical uses and justifications for either one, and
I could also imagine clients guessing either behaviour when just looking
at the function name in code.

Call sites will probably be more clear if they don't use this function,
and instead write out the code:

```
// Is "S" the coarse-grained native style?
if (is_style_windows(S) == is_style_windows(Style::native))

// Is "S" the fine-grained native style?
if (is_style_windows(S) == is_style_windows(Style::native) &&
preferred_separator(S) == preferred_separator(Style::native))
```

Can always add this again if someone needs it and can justify one
behaviour over the other, but for now might as well avoid growing users.

show more ...

Support: Reduce stats in fs::copy_file on Darwin

fs::copy_file() on Darwin has a nice optimization to clone the file when
possible. Change the implementation to use clonefile() directly, instead
of

Support: Reduce stats in fs::copy_file on Darwin

fs::copy_file() on Darwin has a nice optimization to clone the file when
possible. Change the implementation to use clonefile() directly, instead
of the higher-level copyfile(). The latter does the wrong thing for
symlinks, which requires calling `stat` first...

With that out of the way, optimistically call clonefile() all the time,
and then for any error that's recoverable try again with copyfile()
(without the COPYFILE_CLONE flag, as before).

Differential Revision: https://reviews.llvm.org/D112250

show more ...

Support: Expose sys::path::is_style_{posix,windows,native}()

Expose three helpers in namespace llvm::sys::path to detect the
path rules followed by sys::path::Style.

- is_style_posix()
- is_style_w

Support: Expose sys::path::is_style_{posix,windows,native}()

Expose three helpers in namespace llvm::sys::path to detect the
path rules followed by sys::path::Style.

- is_style_posix()
- is_style_windows()
- is_style_native()

This are constexpr functions that that will allow a bunch of
path-related code to stop checking `_WIN32`.

Originally I looked at adding system_style(), analogous to
sys::endian::system_endianness(), but future patches (from others) will
add more Windows style variants for slash preferences. These helpers
should be resilient to that change, allowing callers to detect basic
path rules.

Differential Revision: https://reviews.llvm.org/D112288

show more ...

[SystemZ][z/OS] Fix warning caused by umask returning a signed integer type

On z/OS, umask() returns an int because mode_t is type int, however it is being compared to an unsigned int. This patch fi

[SystemZ][z/OS] Fix warning caused by umask returning a signed integer type

On z/OS, umask() returns an int because mode_t is type int, however it is being compared to an unsigned int. This patch fixes the following warning we see when compiling Path.cpp.

```
comparison of integers of different signs: 'const int' and 'const unsigned int'
```

Reviewed By: muiez

Differential Revision: https://reviews.llvm.org/D102326

show more ...

Support: Add move semantics to mapped_file_region

Update llvm::sys::fs::mapped_file_region to have a move constructor and
a move assignment operator, allowing it to be used as an Optional. Also,
upd

Support: Add move semantics to mapped_file_region

Update llvm::sys::fs::mapped_file_region to have a move constructor and
a move assignment operator, allowing it to be used as an Optional. Also,
update FileOutputBuffer's OnDiskBuffer to take advantage of this,
avoiding an extra allocation from the unique_ptr.

A nice follow-up would be to make the mapped_file_region constructor
private and replace its use with a factory function, such as
mapped_file_region::create(), that returns an Expected (or ErrorOr). I
don't plan on doing that immediately, but I might swing back later.

No functionality change, besides the saved allocation in OnDiskBuffer.

Differential Revision: https://reviews.llvm.org/D100159

show more ...

Support: Extract fs::resize_file_before_mapping_readwrite from FileOutputBuffer

Add a variant of `fs::resize_file` for use immediately before opening a
file with `mapped_file_region::readwrite`. On

Support: Extract fs::resize_file_before_mapping_readwrite from FileOutputBuffer

Add a variant of `fs::resize_file` for use immediately before opening a
file with `mapped_file_region::readwrite`. On Windows, `_chsize`
(`ftruncate`) is slow, but `CreateFileMapping` (`mmap`) automatically
extends the file so the call to `fs::resize_file` can be skipped.

This optimization was added to `FileOutputBuffer` in
da9bc2e56d5a5c6332a9def1a0065eb399182b93; this commit just extracts the
logic out and adds a unit test.

Differential Revision: https://reviews.llvm.org/D95490

show more ...

[SystemZ][z/OS][Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text

Problem:
On SystemZ we need to open text files in text mode. On Windows, files opened in text mode adds a C

[SystemZ][z/OS][Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text

Problem:
On SystemZ we need to open text files in text mode. On Windows, files opened in text mode adds a CRLF '\r\n' which may not be desirable.

Solution:
This patch adds two new flags

- OF_CRLF which indicates that CRLF translation is used.
- OF_TextWithCRLF = OF_Text | OF_CRLF indicates that the file is text and uses CRLF translation.

Developers should now use either the OF_Text or OF_TextWithCRLF for text files and OF_None for binary files. If the developer doesn't want carriage returns on Windows, they should use OF_Text, if they do want carriage returns on Windows, they should use OF_TextWithCRLF.

So this is the behaviour per platform with my patch:

z/OS:
OF_None: open in binary mode
OF_Text : open in text mode
OF_TextWithCRLF: open in text mode

Windows:
OF_None: open file with no carriage return
OF_Text: open file with no carriage return
OF_TextWithCRLF: open file with carriage return

The Major change is in llvm/lib/Support/Windows/Path.inc to only set text mode if the OF_CRLF is set.
```
if (Flags & OF_CRLF)
CrtOpenFlags |= _O_TEXT;
```

These following files are the ones that still use OF_Text which I left unchanged. I modified all these except raw_ostream.cpp in recent patches so I know these were previously in Binary mode on Windows.
./llvm/lib/Support/raw_ostream.cpp
./llvm/lib/TableGen/Main.cpp
./llvm/tools/dsymutil/DwarfLinkerForBinary.cpp
./llvm/unittests/Support/Path.cpp
./clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
./clang/lib/Frontend/CompilerInstance.cpp
./clang/lib/Driver/Driver.cpp
./clang/lib/Driver/ToolChains/Clang.cpp

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D99426

show more ...

[Support][Windows] Make sure only executables are found by sys::findProgramByName

The function utilizes Windows' SearchPathW function, which as I found out today, may also return directories. After

[Support][Windows] Make sure only executables are found by sys::findProgramByName

The function utilizes Windows' SearchPathW function, which as I found out today, may also return directories. After looking at the Unix implementation of the file I found that it contains a check whether the found path is also executable. While fixing the Windows implementation, I also learned that sys::fs::access returns successfully when querying whether directories are executable, which the Unix version does not.

This patch makes both of these functions equivalent to their Unix implementation and insures that any path returned by sys::findProgramByName on Windows may only be executable, just like the Unix implementation.

The equivalent additions I have made to the Windows implementation, in the Unix implementation are here:
sys::findProgramByName: https://github.com/llvm/llvm-project/blob/39ecfe614350fa5db7b8f13f81212f8e3831a390/llvm/lib/Support/Unix/Program.inc#L90
sys::fs::access: https://github.com/llvm/llvm-project/blob/c2a84771bb63947695ea50b89160c02b36fb634d/llvm/lib/Support/Unix/Path.inc#L608

I encountered this issue when running the LLVM testsuite. Commands of the form not test ... would fail to correctly execute test.exe, which is part of GnuWin32, as it actually tried to execute a folder called test, which happened to be in a directory on my PATH.

Differential Revision: https://reviews.llvm.org/D99357

show more ...

[unittests] Use std::make_tuple to make some toolchains happy again

My toolchain stopped working (LLVM 8.0, libstdc++ 5.4.0) after 577adda:

06:25:37 ../unittests/Support/Path.cpp:91:7: error: chose

[unittests] Use std::make_tuple to make some toolchains happy again

My toolchain stopped working (LLVM 8.0, libstdc++ 5.4.0) after 577adda:

06:25:37 ../unittests/Support/Path.cpp:91:7: error: chosen constructor is explicit in copy-initialization
06:25:37 {"", false, false}, {"/", true, true}, {"/foo", true, true},
06:25:37 ^~~~~~~~~~~~~~~~~~
06:25:37 /proj/flexasic/app/llvm/8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.4.0/../../../../include/c++/5.4.0/tuple:479:19: note: explicit constructor declared here
06:25:37 constexpr tuple(_UElements&&... __elements)
06:25:37 ^

This commit adds explicit calls to std::make_tuple to work around
the problem.

show more ...

[Support/Path] Add path::is_absolute_gnu

Implements IS_ABSOLUTE_PATH from GNU tools.

C++17 is_absolute behavior is different the from the behavior defined by GNU
tools.

According to cppreference.c

[Support/Path] Add path::is_absolute_gnu

Implements IS_ABSOLUTE_PATH from GNU tools.

C++17 is_absolute behavior is different the from the behavior defined by GNU
tools.

According to cppreference.com, C++17 states: "An absolute path is a path
that unambiguously identifies the location of a file without reference
to an additional starting location."

In other words, the rules are:
1. POSIX style paths with nonempty root directory are absolute.
2. Windows style paths with nonempty root name and root directory are
absolute.
3. No other paths are absolute.

GNU rules are:
1. Paths starting with a path separator are absolute.
2. Windows style paths are also absolute if they start with a character
followed by ':'.
3. No other paths are absolute.

On Windows style the path "C:\Users\Default" has "C:" as root name and "\"
as root directory.

Hence "C:" on Windows is absolute under GNU rules and not absolute under
C++17 because it has no root directory. Likewise "/" and "\" on Windows are
absolute under GNU and are not absolute under C++17 due to empty root name.

Related to PR46368.

Differential Revision: https://reviews.llvm.org/D87667

show more ...

[Support] Class to facilitate file locking

This change define RAII class `FileLocker` and methods `lock` and
`tryLockFor` of the class `raw_fd_stream` to facilitate using file locks.

Differential R

[Support] Class to facilitate file locking

This change define RAII class `FileLocker` and methods `lock` and
`tryLockFor` of the class `raw_fd_stream` to facilitate using file locks.

Differential Revision: https://reviews.llvm.org/D79066

show more ...

[Support] Fix Windows directory_iterator_construct out of bounds

Fix incorrect use of the size of Path when accessing PathUTF16, as the
UTF-16 path can be shorter. Added unit test for coverage of th

[Support] Fix Windows directory_iterator_construct out of bounds

Fix incorrect use of the size of Path when accessing PathUTF16, as the
UTF-16 path can be shorter. Added unit test for coverage of this test
case.

Thanks to Ding Fei (danix800) for the code fix, see
https://reviews.llvm.org/D83321.

Differential Revision: https://reviews.llvm.org/D83689

show more ...

[Support] Add path::user_config_directory for $XDG_CONFIG_HOME etc

Reviewers: hokein

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D83128

Reland: [clang driver] Move default module cache from system temporary directory

This fixes a unit test. Otherwise here is the original commit:

1) Shared writable directories like /tmp are a securi

Reland: [clang driver] Move default module cache from system temporary directory

This fixes a unit test. Otherwise here is the original commit:

1) Shared writable directories like /tmp are a security problem.
2) Systems provide dedicated cache directories these days anyway.
3) This also refines LLVM's cache_directory() on Darwin platforms to use
the Darwin per-user cache directory.

Reviewers: compnerd, aprantl, jakehehrlich, espindola, respindola, ilya-biryukov, pcc, sammccall

Reviewed By: compnerd, sammccall

Subscribers: hiraditya, llvm-commits, cfe-commits

Tags: #clang, #llvm

Differential Revision: https://reviews.llvm.org/D82362

show more ...

[Support][NFC] Tests for root_name(), root_directory() and root_path()

It's literally just doc comments converted to unittests.

Revert "[Support] Add file lock/unlock functions"

This reverts commit f51bc4fb60fbcef26d18eff549fc68307fd46489.
It broke the Solaris buildbots (Builder clang-solaris11-sparcv9 Build #5494
<http://la

Revert "[Support] Add file lock/unlock functions"

This reverts commit f51bc4fb60fbcef26d18eff549fc68307fd46489.
It broke the Solaris buildbots (Builder clang-solaris11-sparcv9 Build #5494
<http://lab.llvm.org:8014/builders/clang-solaris11-sparcv9/builds/54).

show more ...

[Support] Add file lock/unlock functions

New functions `lockFile`, `tryLockFile` and `unlockFile` implement
simple file locking. They lock or unlock entire file. This must be
enough to support simul

[Support] Add file lock/unlock functions

New functions `lockFile`, `tryLockFile` and `unlockFile` implement
simple file locking. They lock or unlock entire file. This must be
enough to support simulataneous writes to log files in parallel builds.

Differential Revision: https://reviews.llvm.org/D78896

show more ...

[Clang] Restore replace_path_prefix instead of startswith

In D49466, sys::path::replace_path_prefix was used instead startswith for -f[macro/debug/file]-prefix-map options.
However those were revert

[Clang] Restore replace_path_prefix instead of startswith

In D49466, sys::path::replace_path_prefix was used instead startswith for -f[macro/debug/file]-prefix-map options.
However those were reverted later (commit rG3bb24bf25767ef5bbcef958b484e7a06d8689204) due to broken Windows tests.

This patch restores those replace_path_prefix calls.
It also modifies the prefix matching to be case-insensitive under Windows.

Differential Revision : https://reviews.llvm.org/D76869

show more ...

Let normalize() for posix style convert backslash to slash unconditionally.

Currently, normalize() for posix replaces backslashes to slashes, except
that two backslashes in sequence are kept as-is.

Let normalize() for posix style convert backslash to slash unconditionally.

Currently, normalize() for posix replaces backslashes to slashes, except
that two backslashes in sequence are kept as-is.

clang calls normalize() to convert \ to / is microsoft compat mode. This
generally works well, but a path like "c:\\foo\\bar.h" with two
backslashes doesn't work due to the exception in normalize().

These paths happen naturally on Windows hosts with e.g.
`#include __FILE__`, and them not working on other hosts makes it
more difficult to write tests for this case.

The special case has been around without justification since this code
was added in r203611 (since then moved around in r215241 r215243). No
integration tests fail if I remove it.

Try removing the special case.

Differential Revision: https://reviews.llvm.org/D79265

show more ...

Add a test to Support.NormalizePath.

Re-land "Optimize path::remove_dots"

This reverts commit fb5fd74685e728b1d5e68d33e9842bcd734b98e6.
Re-instates commit 53913a65b408ade2956061b4c0aaed6bba907403

The fix is to trim off trailing separa

Re-land "Optimize path::remove_dots"

This reverts commit fb5fd74685e728b1d5e68d33e9842bcd734b98e6.
Re-instates commit 53913a65b408ade2956061b4c0aaed6bba907403

The fix is to trim off trailing separators, as in `/foo/bar/` and
produce `/foo/bar`. VFS tests rely on this. I added unit tests for
remove_dots.

show more ...

Revert "Optimize path::remove_dots"

This reverts commit 53913a65b408ade2956061b4c0aaed6bba907403.
Breaks VFSFromYAMLTest.DirectoryIterationSameDirMultipleEntries
in SupportTests on non-Windows.

Optimize path::remove_dots

LLD calls this on every source file string in every object file when
writing PDBs, so it is somewhat hot.

Avoid rewriting paths that do not contain path traversal compone

Optimize path::remove_dots

LLD calls this on every source file string in every object file when
writing PDBs, so it is somewhat hot.

Avoid rewriting paths that do not contain path traversal components
(./..). Use find_first_not_of(separators) directly instead of using the
path iterators. The path component iterators appear to be slow, and
directly searching for slashes makes it easier to find double separators
that need to be canonicalized.

I discovered that the VFS relies on remote_dots to not canonicalize
early slashes (/foo or C:/foo) on Windows, so I had to leave that
behavior behind with unit tests for it. This is undesirable, but I claim
that my change is NFC.

show more ...

Fix pr31836 on Windows too, and correctly handle repeated separators.

The approach in D30000 assumes that the '/' returned by path::begin()
is the first element for absolute paths, but that's not tr

Fix pr31836 on Windows too, and correctly handle repeated separators.

The approach in D30000 assumes that the '/' returned by path::begin()
is the first element for absolute paths, but that's not true on
Windows.

Also, on Windows backslashes in include lines often end up escaped
so that there are two of them. Having backslashes in include lines
is undefined behavior in most cases and implementation-defined
behavior in C++20, but since clang treats it as normal repeated
path separators, the diagnostic should too.

Unbreaks -Wnonportable-include-path for absolute paths on Windows,
and unbreaks it on non-Windows in the case of absolute paths with
repeated directory separators.

This affects e.g. the `#include __FILE__` technique if the file
passed to clang has the wrong case for the drive letter. Before:

C:\src\llvm-project>bin\clang-cl.exe c:\src\llvm-project\test.cc
c:\\src\\llvm-project\\test.cc(4,10): warning: non-portable path to file
'"c\\srccllvm-projectctest.cc.'; specified path differs in case from
file name on disk [-Wnonportable-include-path]
^

Now:

C:\src\llvm-project> out\gn\bin\clang-cl c:\src\llvm-project\test.cc
c:\\src\\llvm-project\\test.cc(4,10): warning: non-portable path to file
'"C:\\src\\llvm-project\\test.cc"'; specified path differs in case from
file name on disk [-Wnonportable-include-path]
^

Differential Revision: https://reviews.llvm.org/D79223

show more ...

Reland "Add a facility to get system cache directory and use it in clangd"

This reverts commit faf2dce1dd6ae25aa75d2685ac7bb27ec31e2ced.