History log of /llvm-project/llvm/lib/Support/Path.cpp (Results 1 – 25 of 208)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5
# d44ea718 20-Nov-2024 Kazu Hirata <kazu@google.com>

[Support] Remove unused includes (NFC) (#116752)

Identified with misc-include-cleaner.


Revision tags: llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2
# ba13fa2a 09-Mar-2024 Michael Spencer <bigcheesegs@gmail.com>

[llvm][Support] Add and use errnoAsErrorCode (#84423)

LLVM is inconsistent about how it converts `errno` to `std::error_code`.
This can cause problems because values outside of `std::errc` compare

[llvm][Support] Add and use errnoAsErrorCode (#84423)

LLVM is inconsistent about how it converts `errno` to `std::error_code`.
This can cause problems because values outside of `std::errc` compare
differently if one is system and one is generic on POSIX systems.

This is even more of a problem on Windows where use of the system
category is just wrong, as that is for Windows errors, which have a
completely different mapping than POSIX/generic errors. This patch fixes
one instance of this mistake in `JSONTransport.cpp`.

This patch adds `errnoAsErrorCode()` which makes it so people do not
need to think about this issue in the future. It also cleans up a lot of
usage of `errno` in LLVM and Clang.

show more ...


Revision tags: llvmorg-18.1.1
# 310ed337 29-Feb-2024 Jonas Devlieghere <jonas@devlieghere.com>

[Support] Use all_read | all_write for createTemporaryFile (#83360)

In a04879ce7dd6, dsymutil switched from using TempFile to
createTemporaryFile. This caused a regression because the two use
diff

[Support] Use all_read | all_write for createTemporaryFile (#83360)

In a04879ce7dd6, dsymutil switched from using TempFile to
createTemporaryFile. This caused a regression because the two use
different permissions:

- TempFile opens the file as all_read | all_write
- createTemporaryFile opens the file as owner_read | owner_write

The latter turns out to be problematic for dsymutil because it either
promotes the temporary to a proper output file, or it would pass it to
`lipo` to create a universal binary and `lipo` preserves the permissions
of the input files. Either way, this caused issues when the build system
was run as a different user than the one ingesting the resulting
binaries.

I did some version control archeology and I couldn't find evidence that
these permissions were chosen purposely. Both could be considered
reasonable default.

This patch changes the permissions to `all read | all write` to make the
two consistent and match the one currently used by the higher level
abstraction (TempFile).

rdar://123722848

show more ...


Revision tags: llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init
# 361016f6 18-Jan-2024 Matheus Izvekov <mizvekov@gmail.com>

[Path] Fix off-by-one in finding filename for win style paths (#78055)

This fixes a crash where `path::parent_path` causes an invalid access on
a string upon receiving a path that consists of a sin

[Path] Fix off-by-one in finding filename for win style paths (#78055)

This fixes a crash where `path::parent_path` causes an invalid access on
a string upon receiving a path that consists of a single colon.

On Windows machine, with runtime checks enabled build, upon `clang -I:
test.cc` produces:
```
Assertion failed: Index < Length && "Invalid index!", file llvm\include\llvm/ADT/StringRef.h, line 232
...
#6 0x00007ff7816201eb `anonymous namespace'::parent_path_end llvm\lib\Support\Path.cpp:144:0
#7 0x00007ff781620135 llvm::sys::path::parent_path(class llvm::StringRef, enum llvm::sys::path::Style) llvm\lib\Support\Path.cpp:470:0
```

Ideally, we can look for the last colon starting from the last
character, but we can instead start from second to last, and handle
empty paths by abusing `0 - 1 == npos`.

show more ...


# 7e6482b3 18-Jan-2024 Kazu Hirata <kazu@google.com>

[Support] Use SmallString::operator std::string (NFC)


Revision tags: llvmorg-17.0.6, llvmorg-17.0.5
# bcb685e1 03-Nov-2023 Simon Pilgrim <llvm-dev@redking.me.uk>

[Support] Use StringRef::starts_with/ends_with instead of startswith/endswith. NFC.

startswith/endswith wrap starts_with/ends_with and will eventually go away (to more closely match string_view)


Revision tags: llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init
# b0abd489 17-Jun-2023 Elliot Goodrich <elliotgoodrich@gmail.com>

[llvm] Add missing StringExtras.h includes

In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing

[llvm] Add missing StringExtras.h includes

In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing includes that were previously included transitively
through this header.

show more ...


Revision tags: llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3
# e13d1b52 29-Apr-2023 NAKAMURA Takumi <geek4civic@gmail.com>

llvm/lib: Use <cerrno> explicitly since D146395 has hidden `errno`

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


Revision tags: llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3
# 3e57aa30 10-Feb-2023 Alex Brachet <abrachet@google.com>

[llvm-driver] Reinvoke clang as described by llvm driver extra args

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


Revision tags: llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init
# a288d7f9 16-Jan-2023 Joe Loser <joeloser@fastmail.com>

[llvm][ADT] Replace uses of `makeMutableArrayRef` with deduction guides

Similar to how `makeArrayRef` is deprecated in favor of deduction guides, do the
same for `makeMutableArrayRef`.

Once all of

[llvm][ADT] Replace uses of `makeMutableArrayRef` with deduction guides

Similar to how `makeArrayRef` is deprecated in favor of deduction guides, do the
same for `makeMutableArrayRef`.

Once all of the places in-tree are using the deduction guides for
`MutableArrayRef`, we can mark `makeMutableArrayRef` as deprecated.

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

show more ...


Revision tags: llvmorg-15.0.7
# 38818b60 04-Jan-2023 serge-sans-paille <sguelton@mozilla.com>

Move from llvm::makeArrayRef to ArrayRef deduction guides - llvm/ part

Use deduction guides instead of helper functions.

The only non-automatic changes have been:

1. ArrayRef(some_uint8_pointer, 0

Move from llvm::makeArrayRef to ArrayRef deduction guides - llvm/ part

Use deduction guides instead of helper functions.

The only non-automatic changes have been:

1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*))
2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase.
3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated.
4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that).

Per reviewers' comment, some useless makeArrayRef have been removed in the process.

This is a follow-up to https://reviews.llvm.org/D140896 that introduced
the deduction guides.

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

show more ...


Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5
# f06abbb3 06-Jun-2022 Chris Bieneman <chris.bieneman@me.com>

LLVM Driver Multicall tool

This patch adds an llvm-driver multicall tool that can combine multiple
LLVM-based tools. The build infrastructure is enabled for a tool by
adding the GENERATE_DRIVER opti

LLVM Driver Multicall tool

This patch adds an llvm-driver multicall tool that can combine multiple
LLVM-based tools. The build infrastructure is enabled for a tool by
adding the GENERATE_DRIVER option to the add_llvm_executable CMake
call, and changing the tool's main function to a canonicalized
tool_name_main format (i.e. llvm_ar_main, clang_main, etc...).

As currently implemented llvm-driver contains dsymutil, llvm-ar,
llvm-cxxfilt, llvm-objcopy, and clang (if clang is included in the
build).

llvm-driver can be enabled from builds by setting
LLVM_TOOL_LLVM_DRIVER_BUILD=On.

There are several limitations in the current implementation, which can
be addressed in subsequent patches:

(1) the multicall binary cannot currently properly handle
multi-dispatch tools. This means symlinking llvm-ranlib to llvm-driver
will not properly result in llvm-ar's main being called.
(2) the multicall binary cannot be comprised of tools containing
conflicting cl::opt options as the global cl::opt option list cannot
contain duplicates.

These limitations can be addressed in subsequent patches.

Differential revision: https://reviews.llvm.org/D109977

show more ...


# 35ab2a11 02-Jun-2022 Paul Pluzhnikov <ppluzhnikov@google.com>

Fix a buglet in remove_dots().

The function promises to canonicalize the path, but neglected to do so
for the root component.

For example, calling remove_dots("/tmp/foo.c", Style::windows_backslash

Fix a buglet in remove_dots().

The function promises to canonicalize the path, but neglected to do so
for the root component.

For example, calling remove_dots("/tmp/foo.c", Style::windows_backslash)
resulted in "/tmp\foo.c". Now it produces "\tmp\foo.c".

Also fix FIXME in the corresponding test.

Reviewed By: rnk

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

show more ...


Revision tags: llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3
# fbbc41f8 09-Mar-2022 serge-sans-paille <sguelton@redhat.com>

Cleanup include: TableGen

This also includes a few cleanup from Support.

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.l

Cleanup include: TableGen

This also includes a few cleanup from Support.

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121331

show more ...


Revision tags: llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init
# 659bf6d0 27-Jan-2022 Shezan Baig <sbaig1@bloomberg.net>

[Support] [Windows] Don't cancel delete if we failed to set delete

Following up on commit 177176f75c6fa3f624d6d964b9d340ce39511565, if we
failed to setDeleteDisposition(true) during TempFile creatio

[Support] [Windows] Don't cancel delete if we failed to set delete

Following up on commit 177176f75c6fa3f624d6d964b9d340ce39511565, if we
failed to setDeleteDisposition(true) during TempFile creation, then
don't try to setDeleteDisposition(false) during TempFile::keep, since it
will likely fail as well.

Instead of letting TempFile::keep just fail, we should let it go ahead
and try renaming the file.

This fixes an issue we are seeing when running clang-cl.exe through the
Incredibuild distributed build system. We're seeing that renaming
temporary object files would fail here:
https://github.com/llvm/llvm-project/blob/5c1f7b296ac0dddeca02891976e6ab5cfc006719/clang/lib/Frontend/CompilerInstance.cpp#L789

Reviewed By: mstorsjo

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

show more ...


Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2
# 345223a7 07-Dec-2021 Duncan P. N. Exon Smith <dexonsmith@apple.com>

Support: Extract sys::fs::readNativeFileToEOF() from MemoryBuffer

Extract the `readNativeFile()` loop from
`MemoryBuffer::getMemoryBufferForStream()` into `readNativeFileToEOF()`
to allow reuse. The

Support: Extract sys::fs::readNativeFileToEOF() from MemoryBuffer

Extract the `readNativeFile()` loop from
`MemoryBuffer::getMemoryBufferForStream()` into `readNativeFileToEOF()`
to allow reuse. The chunk size is configurable; the default of `4*4096`
is exposed as `sys::fs::DefaultReadChunkSize` to allow sizing of
SmallVectors.

There's somewhere I'd like to read a usually-small file without overhead
of a MemoryBuffer; extracting existing logic rather than duplicating it.

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

show more ...


# 7df18557 08-Dec-2021 Duncan P. N. Exon Smith <dexonsmith@apple.com>

Support: Avoid using SmallVector::set_size() in sys::path

Stop using `SmallVector::set_size()` in sys::path APIs. In both cases,
use `truncate()` instead.

Differential Revision: https://reviews.llv

Support: Avoid using SmallVector::set_size() in sys::path

Stop using `SmallVector::set_size()` in sys::path APIs. In both cases,
use `truncate()` instead.

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

show more ...


Revision tags: llvmorg-13.0.1-rc1
# df0ba47c 13-Oct-2021 Martin Storsjö <martin@martin.st>

[Support] Allow configuring the preferred type of slashes on Windows

Default to preferring forward slashes when built for MinGW, as
many usecases, when e.g. Clang is used as a drop-in replacement
fo

[Support] Allow configuring the preferred type of slashes on Windows

Default to preferring forward slashes when built for MinGW, as
many usecases, when e.g. Clang is used as a drop-in replacement
for GCC, requires the compiler to output paths with forward slashes.

Not all tests pass yet, if configuring to prefer forward slashes though.

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

show more ...


# a8b54834 04-Oct-2021 Martin Storsjö <martin@martin.st>

[Support] Add a new path style for Windows with forward slashes

This behaves just like the regular Windows style, with both separator
forms accepted, but with get_separator() returning forward slash

[Support] Add a new path style for Windows with forward slashes

This behaves just like the regular Windows style, with both separator
forms accepted, but with get_separator() returning forward slashes.

Add a more descriptive name for the existing style, keeping the old
name around as an alias initially.

Add a new function `make_preferred()` (like the C++17
`std::filesystem::path` function with the same name), which converts
windows paths to the preferred separator form (while this one works on
any platform and takes a `path::Style` argument).

Contrary to `native()` (just like `make_preferred()` in `std::filesystem`),
this doesn't do anything at all on Posix, it doesn't try to reinterpret
backslashes into forward slashes there.

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

show more ...


# a39eba72 28-Oct-2021 Martin Storsjö <martin@martin.st>

[Support] [Windows] Use RemoveFileOnSignal if unable to use the delete-on-close flag

This takes care of cleaning up the temp files on crashes. It doesn't
handle cleanup when explicitly killed though

[Support] [Windows] Use RemoveFileOnSignal if unable to use the delete-on-close flag

This takes care of cleaning up the temp files on crashes. It doesn't
handle cleanup when explicitly killed though.

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

show more ...


# 99023627 22-Oct-2021 Duncan P. N. Exon Smith <dexonsmith@apple.com>

Support: Use sys::path::is_style_{posix,windows}() in a few places

Use the new sys::path::is_style_posix() and is_style_windows() in a few
places that need to detect the system's native path style.

Support: Use sys::path::is_style_{posix,windows}() in a few places

Use the new sys::path::is_style_posix() and is_style_windows() in a few
places that need to detect the system's native path style.

In llvm/lib/Support/Path.cpp, this patch removes most uses of the
private `real_style()`, where is_style_posix() and is_style_windows()
are just a little tidier.

Elsewhere, this removes `_WIN32` macro checks. Added a FIXME to a
FileManagerTest that seemed fishy, but maintained the existing
behaviour.

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

show more ...


Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4
# 4e4883e1 16-Sep-2021 Duncan P. N. Exon Smith <dexonsmith@apple.com>

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 ...


# 177176f7 04-Oct-2021 Martin Storsjö <martin@martin.st>

[Support] [Windows] Manually clean up temp files if not setting delete disposition

Since D81803 / 79657e2339b58bc01fe1b85a448bb073d57d90bb, temp files
created on network shares don't set "Dispositio

[Support] [Windows] Manually clean up temp files if not setting delete disposition

Since D81803 / 79657e2339b58bc01fe1b85a448bb073d57d90bb, temp files
created on network shares don't set "Disposition.DeleteFile = true".
This flag normally takes care of removing the temp file both if the
process exits abnormally (either crashing or killed externally), and
when the file is closed cleanly.

For network shares, we voluntarily choose to not set the flag, and
if the operation to inspect the file handle (as a prerequisite to
setting the flag since 79657e2339b58bc01fe1b85a448bb073d57d90bb)
fails we also error out. In both of these cases, we can at least make
sure to remove the temp files when they are closed cleanly.

Adjust the semantics of "OF_Delete" to not set the delete
disposition, but only set the access mode for allowing deletion.
Move the call to setDeleteDisposition into TempFile::create,
where we can check if it failed, and if it did, set a flag noting
that the file should be removed manually at the end.

This does leak files on crash, but at least doesn't leak files
in regular successful runs. (Technically, the alternative codepath
could use the RemoveFileOnSignal function, but that might complicate
the TempFile implementation further.)

This fixes https://github.com/mstorsjo/llvm-mingw/issues/233 and
https://bugs.llvm.org/show_bug.cgi?id=52080.

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

show more ...


# 2a4b1539 04-Oct-2021 Martin Storsjö <martin@martin.st>

[Support] [Path] Use std::replace instead of an explicit comparison loop. NFC.

After 8fc7a907b93a8e9eef96e872f8f926db3ebfe9b6, this loop does
the same as a plain `std::replace`.

Also clarify the co

[Support] [Path] Use std::replace instead of an explicit comparison loop. NFC.

After 8fc7a907b93a8e9eef96e872f8f926db3ebfe9b6, this loop does
the same as a plain `std::replace`.

Also clarify the comment about what this function does.

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

show more ...


Revision tags: llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2
# 0e8506de 08-Jun-2021 Abhina Sreeskantharajan <Abhina.Sreeskantharajan@ibm.com>

[SystemZ][z/OS] Pass OpenFlags when creating tmp files

This patch https://reviews.llvm.org/D102876 caused some lit regressions on z/OS because tmp files were no longer being opened based on binary/t

[SystemZ][z/OS] Pass OpenFlags when creating tmp files

This patch https://reviews.llvm.org/D102876 caused some lit regressions on z/OS because tmp files were no longer being opened based on binary/text mode. This patch passes OpenFlags when creating tmp files so we can open files in different modes.

Reviewed By: amccarth

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

show more ...


123456789