Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
// -*- C++ -*-
|
|
|
|
//===--------------------------- filesystem -------------------------------===//
|
|
|
|
//
|
2019-01-19 18:56:40 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
#ifndef _LIBCPP_FILESYSTEM
|
|
|
|
#define _LIBCPP_FILESYSTEM
|
|
|
|
/*
|
|
|
|
filesystem synopsis
|
|
|
|
|
|
|
|
namespace std { namespace filesystem {
|
|
|
|
|
|
|
|
class path;
|
|
|
|
|
|
|
|
void swap(path& lhs, path& rhs) noexcept;
|
|
|
|
size_t hash_value(const path& p) noexcept;
|
|
|
|
|
|
|
|
bool operator==(const path& lhs, const path& rhs) noexcept;
|
|
|
|
bool operator!=(const path& lhs, const path& rhs) noexcept;
|
|
|
|
bool operator< (const path& lhs, const path& rhs) noexcept;
|
|
|
|
bool operator<=(const path& lhs, const path& rhs) noexcept;
|
|
|
|
bool operator> (const path& lhs, const path& rhs) noexcept;
|
|
|
|
bool operator>=(const path& lhs, const path& rhs) noexcept;
|
|
|
|
|
|
|
|
path operator/ (const path& lhs, const path& rhs);
|
|
|
|
|
|
|
|
// fs.path.io operators are friends of path.
|
|
|
|
template <class charT, class traits>
|
|
|
|
friend basic_ostream<charT, traits>&
|
|
|
|
operator<<(basic_ostream<charT, traits>& os, const path& p);
|
|
|
|
|
|
|
|
template <class charT, class traits>
|
|
|
|
friend basic_istream<charT, traits>&
|
|
|
|
operator>>(basic_istream<charT, traits>& is, path& p);
|
|
|
|
|
|
|
|
template <class Source>
|
|
|
|
path u8path(const Source& source);
|
|
|
|
template <class InputIterator>
|
|
|
|
path u8path(InputIterator first, InputIterator last);
|
|
|
|
|
|
|
|
class filesystem_error;
|
|
|
|
class directory_entry;
|
|
|
|
|
|
|
|
class directory_iterator;
|
|
|
|
|
|
|
|
// enable directory_iterator range-based for statements
|
|
|
|
directory_iterator begin(directory_iterator iter) noexcept;
|
|
|
|
directory_iterator end(const directory_iterator&) noexcept;
|
|
|
|
|
|
|
|
class recursive_directory_iterator;
|
|
|
|
|
|
|
|
// enable recursive_directory_iterator range-based for statements
|
|
|
|
recursive_directory_iterator begin(recursive_directory_iterator iter) noexcept;
|
|
|
|
recursive_directory_iterator end(const recursive_directory_iterator&) noexcept;
|
|
|
|
|
|
|
|
class file_status;
|
|
|
|
|
|
|
|
struct space_info
|
|
|
|
{
|
|
|
|
uintmax_t capacity;
|
|
|
|
uintmax_t free;
|
|
|
|
uintmax_t available;
|
|
|
|
};
|
|
|
|
|
|
|
|
enum class file_type;
|
|
|
|
enum class perms;
|
|
|
|
enum class perm_options;
|
|
|
|
enum class copy_options;
|
|
|
|
enum class directory_options;
|
|
|
|
|
|
|
|
typedef chrono::time_point<trivial-clock> file_time_type;
|
|
|
|
|
|
|
|
// operational functions
|
|
|
|
|
|
|
|
path absolute(const path& p);
|
|
|
|
path absolute(const path& p, error_code &ec);
|
|
|
|
|
|
|
|
path canonical(const path& p);
|
|
|
|
path canonical(const path& p, error_code& ec);
|
|
|
|
|
|
|
|
void copy(const path& from, const path& to);
|
|
|
|
void copy(const path& from, const path& to, error_code& ec);
|
|
|
|
void copy(const path& from, const path& to, copy_options options);
|
|
|
|
void copy(const path& from, const path& to, copy_options options,
|
|
|
|
error_code& ec);
|
|
|
|
|
|
|
|
bool copy_file(const path& from, const path& to);
|
|
|
|
bool copy_file(const path& from, const path& to, error_code& ec);
|
|
|
|
bool copy_file(const path& from, const path& to, copy_options option);
|
|
|
|
bool copy_file(const path& from, const path& to, copy_options option,
|
|
|
|
error_code& ec);
|
|
|
|
|
|
|
|
void copy_symlink(const path& existing_symlink, const path& new_symlink);
|
|
|
|
void copy_symlink(const path& existing_symlink, const path& new_symlink,
|
|
|
|
error_code& ec) noexcept;
|
|
|
|
|
|
|
|
bool create_directories(const path& p);
|
|
|
|
bool create_directories(const path& p, error_code& ec);
|
|
|
|
|
|
|
|
bool create_directory(const path& p);
|
|
|
|
bool create_directory(const path& p, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
bool create_directory(const path& p, const path& attributes);
|
|
|
|
bool create_directory(const path& p, const path& attributes,
|
|
|
|
error_code& ec) noexcept;
|
|
|
|
|
|
|
|
void create_directory_symlink(const path& to, const path& new_symlink);
|
|
|
|
void create_directory_symlink(const path& to, const path& new_symlink,
|
|
|
|
error_code& ec) noexcept;
|
|
|
|
|
|
|
|
void create_hard_link(const path& to, const path& new_hard_link);
|
|
|
|
void create_hard_link(const path& to, const path& new_hard_link,
|
|
|
|
error_code& ec) noexcept;
|
|
|
|
|
|
|
|
void create_symlink(const path& to, const path& new_symlink);
|
|
|
|
void create_symlink(const path& to, const path& new_symlink,
|
|
|
|
error_code& ec) noexcept;
|
|
|
|
|
|
|
|
path current_path();
|
|
|
|
path current_path(error_code& ec);
|
|
|
|
void current_path(const path& p);
|
|
|
|
void current_path(const path& p, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
bool exists(file_status s) noexcept;
|
|
|
|
bool exists(const path& p);
|
|
|
|
bool exists(const path& p, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
bool equivalent(const path& p1, const path& p2);
|
|
|
|
bool equivalent(const path& p1, const path& p2, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
uintmax_t file_size(const path& p);
|
|
|
|
uintmax_t file_size(const path& p, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
uintmax_t hard_link_count(const path& p);
|
|
|
|
uintmax_t hard_link_count(const path& p, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
bool is_block_file(file_status s) noexcept;
|
|
|
|
bool is_block_file(const path& p);
|
|
|
|
bool is_block_file(const path& p, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
bool is_character_file(file_status s) noexcept;
|
|
|
|
bool is_character_file(const path& p);
|
|
|
|
bool is_character_file(const path& p, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
bool is_directory(file_status s) noexcept;
|
|
|
|
bool is_directory(const path& p);
|
|
|
|
bool is_directory(const path& p, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
bool is_empty(const path& p);
|
|
|
|
bool is_empty(const path& p, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
bool is_fifo(file_status s) noexcept;
|
|
|
|
bool is_fifo(const path& p);
|
|
|
|
bool is_fifo(const path& p, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
bool is_other(file_status s) noexcept;
|
|
|
|
bool is_other(const path& p);
|
|
|
|
bool is_other(const path& p, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
bool is_regular_file(file_status s) noexcept;
|
|
|
|
bool is_regular_file(const path& p);
|
|
|
|
bool is_regular_file(const path& p, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
bool is_socket(file_status s) noexcept;
|
|
|
|
bool is_socket(const path& p);
|
|
|
|
bool is_socket(const path& p, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
bool is_symlink(file_status s) noexcept;
|
|
|
|
bool is_symlink(const path& p);
|
|
|
|
bool is_symlink(const path& p, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
file_time_type last_write_time(const path& p);
|
|
|
|
file_time_type last_write_time(const path& p, error_code& ec) noexcept;
|
|
|
|
void last_write_time(const path& p, file_time_type new_time);
|
|
|
|
void last_write_time(const path& p, file_time_type new_time,
|
|
|
|
error_code& ec) noexcept;
|
|
|
|
|
|
|
|
void permissions(const path& p, perms prms,
|
|
|
|
perm_options opts=perm_options::replace);
|
|
|
|
void permissions(const path& p, perms prms, error_code& ec) noexcept;
|
|
|
|
void permissions(const path& p, perms prms, perm_options opts,
|
|
|
|
error_code& ec);
|
|
|
|
|
|
|
|
path proximate(const path& p, error_code& ec);
|
|
|
|
path proximate(const path& p, const path& base = current_path());
|
|
|
|
path proximate(const path& p, const path& base, error_code &ec);
|
|
|
|
|
|
|
|
path read_symlink(const path& p);
|
|
|
|
path read_symlink(const path& p, error_code& ec);
|
|
|
|
|
|
|
|
path relative(const path& p, error_code& ec);
|
|
|
|
path relative(const path& p, const path& base=current_path());
|
|
|
|
path relative(const path& p, const path& base, error_code& ec);
|
|
|
|
|
|
|
|
bool remove(const path& p);
|
|
|
|
bool remove(const path& p, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
uintmax_t remove_all(const path& p);
|
|
|
|
uintmax_t remove_all(const path& p, error_code& ec);
|
|
|
|
|
|
|
|
void rename(const path& from, const path& to);
|
|
|
|
void rename(const path& from, const path& to, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
void resize_file(const path& p, uintmax_t size);
|
|
|
|
void resize_file(const path& p, uintmax_t size, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
space_info space(const path& p);
|
|
|
|
space_info space(const path& p, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
file_status status(const path& p);
|
|
|
|
file_status status(const path& p, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
bool status_known(file_status s) noexcept;
|
|
|
|
|
|
|
|
file_status symlink_status(const path& p);
|
|
|
|
file_status symlink_status(const path& p, error_code& ec) noexcept;
|
|
|
|
|
|
|
|
path temp_directory_path();
|
|
|
|
path temp_directory_path(error_code& ec);
|
|
|
|
|
|
|
|
path weakly_canonical(path const& p);
|
|
|
|
path weakly_canonical(path const& p, error_code& ec);
|
|
|
|
|
|
|
|
|
|
|
|
} } // namespaces std::filesystem
|
|
|
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <__config>
|
2020-11-05 04:01:25 +08:00
|
|
|
#include <__availability>
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
#include <cstddef>
|
|
|
|
#include <cstdlib>
|
|
|
|
#include <chrono>
|
2021-03-25 06:19:12 +08:00
|
|
|
#include <compare>
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
#include <iterator>
|
|
|
|
#include <iosfwd>
|
|
|
|
#include <memory>
|
|
|
|
#include <stack>
|
|
|
|
#include <string>
|
|
|
|
#include <system_error>
|
|
|
|
#include <utility>
|
|
|
|
#include <string_view>
|
2018-09-13 03:41:40 +08:00
|
|
|
#include <version>
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
|
2020-10-10 03:31:05 +08:00
|
|
|
#if !defined(_LIBCPP_HAS_NO_LOCALIZATION)
|
|
|
|
# include <locale>
|
|
|
|
# include <iomanip> // for quoted
|
|
|
|
#endif
|
|
|
|
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
#include <__debug>
|
|
|
|
|
2021-01-19 01:18:18 +08:00
|
|
|
#if defined(_LIBCPP_HAS_NO_FILESYSTEM_LIBRARY)
|
|
|
|
# error "The Filesystem library is not supported by this configuration of libc++"
|
|
|
|
#endif
|
|
|
|
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
|
|
|
|
#pragma GCC system_header
|
|
|
|
#endif
|
|
|
|
|
|
|
|
_LIBCPP_PUSH_MACROS
|
|
|
|
#include <__undef_macros>
|
|
|
|
|
|
|
|
#ifndef _LIBCPP_CXX03_LANG
|
|
|
|
|
|
|
|
_LIBCPP_BEGIN_NAMESPACE_FILESYSTEM
|
|
|
|
|
2019-03-21 05:18:14 +08:00
|
|
|
_LIBCPP_AVAILABILITY_FILESYSTEM_PUSH
|
|
|
|
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
typedef chrono::time_point<_FilesystemClock> file_time_type;
|
|
|
|
|
|
|
|
struct _LIBCPP_TYPE_VIS space_info {
|
|
|
|
uintmax_t capacity;
|
|
|
|
uintmax_t free;
|
|
|
|
uintmax_t available;
|
|
|
|
};
|
|
|
|
|
2021-03-08 05:49:56 +08:00
|
|
|
// On Windows, the library never identifies files as block, character, fifo
|
|
|
|
// or socket.
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
enum class _LIBCPP_ENUM_VIS file_type : signed char {
|
|
|
|
none = 0,
|
|
|
|
not_found = -1,
|
|
|
|
regular = 1,
|
|
|
|
directory = 2,
|
|
|
|
symlink = 3,
|
|
|
|
block = 4,
|
|
|
|
character = 5,
|
|
|
|
fifo = 6,
|
|
|
|
socket = 7,
|
|
|
|
unknown = 8
|
|
|
|
};
|
|
|
|
|
2021-03-08 05:49:56 +08:00
|
|
|
// On Windows, these permission bits map to one single readonly flag per
|
|
|
|
// file, and the executable bit is always returned as set. When setting
|
|
|
|
// permissions, as long as the write bit is set for either owner, group or
|
|
|
|
// others, the readonly flag is cleared.
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
enum class _LIBCPP_ENUM_VIS perms : unsigned {
|
|
|
|
none = 0,
|
|
|
|
|
|
|
|
owner_read = 0400,
|
|
|
|
owner_write = 0200,
|
|
|
|
owner_exec = 0100,
|
|
|
|
owner_all = 0700,
|
|
|
|
|
|
|
|
group_read = 040,
|
|
|
|
group_write = 020,
|
|
|
|
group_exec = 010,
|
|
|
|
group_all = 070,
|
|
|
|
|
|
|
|
others_read = 04,
|
|
|
|
others_write = 02,
|
|
|
|
others_exec = 01,
|
|
|
|
others_all = 07,
|
|
|
|
|
|
|
|
all = 0777,
|
|
|
|
|
|
|
|
set_uid = 04000,
|
|
|
|
set_gid = 02000,
|
|
|
|
sticky_bit = 01000,
|
|
|
|
mask = 07777,
|
|
|
|
unknown = 0xFFFF,
|
|
|
|
};
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline constexpr perms operator&(perms _LHS, perms _RHS) {
|
|
|
|
return static_cast<perms>(static_cast<unsigned>(_LHS) &
|
|
|
|
static_cast<unsigned>(_RHS));
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline constexpr perms operator|(perms _LHS, perms _RHS) {
|
|
|
|
return static_cast<perms>(static_cast<unsigned>(_LHS) |
|
|
|
|
static_cast<unsigned>(_RHS));
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline constexpr perms operator^(perms _LHS, perms _RHS) {
|
|
|
|
return static_cast<perms>(static_cast<unsigned>(_LHS) ^
|
|
|
|
static_cast<unsigned>(_RHS));
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline constexpr perms operator~(perms _LHS) {
|
|
|
|
return static_cast<perms>(~static_cast<unsigned>(_LHS));
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline perms& operator&=(perms& _LHS, perms _RHS) { return _LHS = _LHS & _RHS; }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline perms& operator|=(perms& _LHS, perms _RHS) { return _LHS = _LHS | _RHS; }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline perms& operator^=(perms& _LHS, perms _RHS) { return _LHS = _LHS ^ _RHS; }
|
|
|
|
|
|
|
|
enum class _LIBCPP_ENUM_VIS perm_options : unsigned char {
|
|
|
|
replace = 1,
|
|
|
|
add = 2,
|
|
|
|
remove = 4,
|
|
|
|
nofollow = 8
|
|
|
|
};
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline constexpr perm_options operator&(perm_options _LHS, perm_options _RHS) {
|
|
|
|
return static_cast<perm_options>(static_cast<unsigned>(_LHS) &
|
|
|
|
static_cast<unsigned>(_RHS));
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline constexpr perm_options operator|(perm_options _LHS, perm_options _RHS) {
|
|
|
|
return static_cast<perm_options>(static_cast<unsigned>(_LHS) |
|
|
|
|
static_cast<unsigned>(_RHS));
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline constexpr perm_options operator^(perm_options _LHS, perm_options _RHS) {
|
|
|
|
return static_cast<perm_options>(static_cast<unsigned>(_LHS) ^
|
|
|
|
static_cast<unsigned>(_RHS));
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline constexpr perm_options operator~(perm_options _LHS) {
|
|
|
|
return static_cast<perm_options>(~static_cast<unsigned>(_LHS));
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline perm_options& operator&=(perm_options& _LHS, perm_options _RHS) {
|
|
|
|
return _LHS = _LHS & _RHS;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline perm_options& operator|=(perm_options& _LHS, perm_options _RHS) {
|
|
|
|
return _LHS = _LHS | _RHS;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline perm_options& operator^=(perm_options& _LHS, perm_options _RHS) {
|
|
|
|
return _LHS = _LHS ^ _RHS;
|
|
|
|
}
|
|
|
|
|
|
|
|
enum class _LIBCPP_ENUM_VIS copy_options : unsigned short {
|
|
|
|
none = 0,
|
|
|
|
skip_existing = 1,
|
|
|
|
overwrite_existing = 2,
|
|
|
|
update_existing = 4,
|
|
|
|
recursive = 8,
|
|
|
|
copy_symlinks = 16,
|
|
|
|
skip_symlinks = 32,
|
|
|
|
directories_only = 64,
|
|
|
|
create_symlinks = 128,
|
|
|
|
create_hard_links = 256,
|
|
|
|
__in_recursive_copy = 512,
|
|
|
|
};
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline constexpr copy_options operator&(copy_options _LHS, copy_options _RHS) {
|
|
|
|
return static_cast<copy_options>(static_cast<unsigned short>(_LHS) &
|
|
|
|
static_cast<unsigned short>(_RHS));
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline constexpr copy_options operator|(copy_options _LHS, copy_options _RHS) {
|
|
|
|
return static_cast<copy_options>(static_cast<unsigned short>(_LHS) |
|
|
|
|
static_cast<unsigned short>(_RHS));
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline constexpr copy_options operator^(copy_options _LHS, copy_options _RHS) {
|
|
|
|
return static_cast<copy_options>(static_cast<unsigned short>(_LHS) ^
|
|
|
|
static_cast<unsigned short>(_RHS));
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline constexpr copy_options operator~(copy_options _LHS) {
|
|
|
|
return static_cast<copy_options>(~static_cast<unsigned short>(_LHS));
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline copy_options& operator&=(copy_options& _LHS, copy_options _RHS) {
|
|
|
|
return _LHS = _LHS & _RHS;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline copy_options& operator|=(copy_options& _LHS, copy_options _RHS) {
|
|
|
|
return _LHS = _LHS | _RHS;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline copy_options& operator^=(copy_options& _LHS, copy_options _RHS) {
|
|
|
|
return _LHS = _LHS ^ _RHS;
|
|
|
|
}
|
|
|
|
|
|
|
|
enum class _LIBCPP_ENUM_VIS directory_options : unsigned char {
|
|
|
|
none = 0,
|
|
|
|
follow_directory_symlink = 1,
|
|
|
|
skip_permission_denied = 2
|
|
|
|
};
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline constexpr directory_options operator&(directory_options _LHS,
|
|
|
|
directory_options _RHS) {
|
|
|
|
return static_cast<directory_options>(static_cast<unsigned char>(_LHS) &
|
|
|
|
static_cast<unsigned char>(_RHS));
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline constexpr directory_options operator|(directory_options _LHS,
|
|
|
|
directory_options _RHS) {
|
|
|
|
return static_cast<directory_options>(static_cast<unsigned char>(_LHS) |
|
|
|
|
static_cast<unsigned char>(_RHS));
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline constexpr directory_options operator^(directory_options _LHS,
|
|
|
|
directory_options _RHS) {
|
|
|
|
return static_cast<directory_options>(static_cast<unsigned char>(_LHS) ^
|
|
|
|
static_cast<unsigned char>(_RHS));
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline constexpr directory_options operator~(directory_options _LHS) {
|
|
|
|
return static_cast<directory_options>(~static_cast<unsigned char>(_LHS));
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline directory_options& operator&=(directory_options& _LHS,
|
|
|
|
directory_options _RHS) {
|
|
|
|
return _LHS = _LHS & _RHS;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline directory_options& operator|=(directory_options& _LHS,
|
|
|
|
directory_options _RHS) {
|
|
|
|
return _LHS = _LHS | _RHS;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline directory_options& operator^=(directory_options& _LHS,
|
|
|
|
directory_options _RHS) {
|
|
|
|
return _LHS = _LHS ^ _RHS;
|
|
|
|
}
|
|
|
|
|
|
|
|
class _LIBCPP_TYPE_VIS file_status {
|
|
|
|
public:
|
|
|
|
// constructors
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
file_status() noexcept : file_status(file_type::none) {}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
explicit file_status(file_type __ft, perms __prms = perms::unknown) noexcept
|
|
|
|
: __ft_(__ft),
|
|
|
|
__prms_(__prms) {}
|
|
|
|
|
|
|
|
file_status(const file_status&) noexcept = default;
|
|
|
|
file_status(file_status&&) noexcept = default;
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
~file_status() {}
|
|
|
|
|
|
|
|
file_status& operator=(const file_status&) noexcept = default;
|
|
|
|
file_status& operator=(file_status&&) noexcept = default;
|
|
|
|
|
|
|
|
// observers
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
file_type type() const noexcept { return __ft_; }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
perms permissions() const noexcept { return __prms_; }
|
|
|
|
|
|
|
|
// modifiers
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
void type(file_type __ft) noexcept { __ft_ = __ft; }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
void permissions(perms __p) noexcept { __prms_ = __p; }
|
|
|
|
|
|
|
|
private:
|
|
|
|
file_type __ft_;
|
|
|
|
perms __prms_;
|
|
|
|
};
|
|
|
|
|
|
|
|
class _LIBCPP_TYPE_VIS directory_entry;
|
|
|
|
|
|
|
|
template <class _Tp>
|
|
|
|
struct __can_convert_char {
|
|
|
|
static const bool value = false;
|
|
|
|
};
|
|
|
|
template <class _Tp>
|
|
|
|
struct __can_convert_char<const _Tp> : public __can_convert_char<_Tp> {};
|
|
|
|
template <>
|
|
|
|
struct __can_convert_char<char> {
|
|
|
|
static const bool value = true;
|
|
|
|
using __char_type = char;
|
|
|
|
};
|
|
|
|
template <>
|
|
|
|
struct __can_convert_char<wchar_t> {
|
|
|
|
static const bool value = true;
|
|
|
|
using __char_type = wchar_t;
|
|
|
|
};
|
2021-04-19 09:47:08 +08:00
|
|
|
#ifndef _LIBCPP_HAS_NO_CHAR8_T
|
2020-10-26 19:18:46 +08:00
|
|
|
template <>
|
|
|
|
struct __can_convert_char<char8_t> {
|
|
|
|
static const bool value = true;
|
|
|
|
using __char_type = char8_t;
|
|
|
|
};
|
|
|
|
#endif
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
template <>
|
|
|
|
struct __can_convert_char<char16_t> {
|
|
|
|
static const bool value = true;
|
|
|
|
using __char_type = char16_t;
|
|
|
|
};
|
|
|
|
template <>
|
|
|
|
struct __can_convert_char<char32_t> {
|
|
|
|
static const bool value = true;
|
|
|
|
using __char_type = char32_t;
|
|
|
|
};
|
|
|
|
|
|
|
|
template <class _ECharT>
|
|
|
|
typename enable_if<__can_convert_char<_ECharT>::value, bool>::type
|
|
|
|
__is_separator(_ECharT __e) {
|
2020-10-27 19:09:08 +08:00
|
|
|
#if defined(_LIBCPP_WIN32API)
|
|
|
|
return __e == _ECharT('/') || __e == _ECharT('\\');
|
|
|
|
#else
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
return __e == _ECharT('/');
|
2020-10-27 19:09:08 +08:00
|
|
|
#endif
|
2018-10-01 09:59:37 +08:00
|
|
|
}
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
|
2021-04-19 09:47:08 +08:00
|
|
|
#ifndef _LIBCPP_HAS_NO_CHAR8_T
|
2020-10-27 19:09:08 +08:00
|
|
|
typedef u8string __u8_string;
|
|
|
|
#else
|
|
|
|
typedef string __u8_string;
|
|
|
|
#endif
|
|
|
|
|
2020-10-27 17:46:06 +08:00
|
|
|
struct _NullSentinel {};
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
|
|
|
|
template <class _Tp>
|
|
|
|
using _Void = void;
|
|
|
|
|
|
|
|
template <class _Tp, class = void>
|
|
|
|
struct __is_pathable_string : public false_type {};
|
|
|
|
|
|
|
|
template <class _ECharT, class _Traits, class _Alloc>
|
|
|
|
struct __is_pathable_string<
|
|
|
|
basic_string<_ECharT, _Traits, _Alloc>,
|
|
|
|
_Void<typename __can_convert_char<_ECharT>::__char_type> >
|
|
|
|
: public __can_convert_char<_ECharT> {
|
|
|
|
using _Str = basic_string<_ECharT, _Traits, _Alloc>;
|
|
|
|
using _Base = __can_convert_char<_ECharT>;
|
|
|
|
static _ECharT const* __range_begin(_Str const& __s) { return __s.data(); }
|
|
|
|
static _ECharT const* __range_end(_Str const& __s) {
|
|
|
|
return __s.data() + __s.length();
|
|
|
|
}
|
|
|
|
static _ECharT __first_or_null(_Str const& __s) {
|
|
|
|
return __s.empty() ? _ECharT{} : __s[0];
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
template <class _ECharT, class _Traits>
|
|
|
|
struct __is_pathable_string<
|
|
|
|
basic_string_view<_ECharT, _Traits>,
|
|
|
|
_Void<typename __can_convert_char<_ECharT>::__char_type> >
|
|
|
|
: public __can_convert_char<_ECharT> {
|
|
|
|
using _Str = basic_string_view<_ECharT, _Traits>;
|
|
|
|
using _Base = __can_convert_char<_ECharT>;
|
|
|
|
static _ECharT const* __range_begin(_Str const& __s) { return __s.data(); }
|
|
|
|
static _ECharT const* __range_end(_Str const& __s) {
|
|
|
|
return __s.data() + __s.length();
|
|
|
|
}
|
|
|
|
static _ECharT __first_or_null(_Str const& __s) {
|
|
|
|
return __s.empty() ? _ECharT{} : __s[0];
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
template <class _Source, class _DS = typename decay<_Source>::type,
|
|
|
|
class _UnqualPtrType =
|
|
|
|
typename remove_const<typename remove_pointer<_DS>::type>::type,
|
|
|
|
bool _IsCharPtr = is_pointer<_DS>::value&&
|
|
|
|
__can_convert_char<_UnqualPtrType>::value>
|
|
|
|
struct __is_pathable_char_array : false_type {};
|
|
|
|
|
|
|
|
template <class _Source, class _ECharT, class _UPtr>
|
|
|
|
struct __is_pathable_char_array<_Source, _ECharT*, _UPtr, true>
|
|
|
|
: __can_convert_char<typename remove_const<_ECharT>::type> {
|
|
|
|
using _Base = __can_convert_char<typename remove_const<_ECharT>::type>;
|
|
|
|
|
|
|
|
static _ECharT const* __range_begin(const _ECharT* __b) { return __b; }
|
|
|
|
static _ECharT const* __range_end(const _ECharT* __b) {
|
|
|
|
using _Iter = const _ECharT*;
|
2020-10-27 17:46:06 +08:00
|
|
|
const _ECharT __sentinel = _ECharT{};
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
_Iter __e = __b;
|
2020-10-27 17:46:06 +08:00
|
|
|
for (; *__e != __sentinel; ++__e)
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
;
|
|
|
|
return __e;
|
|
|
|
}
|
|
|
|
|
|
|
|
static _ECharT __first_or_null(const _ECharT* __b) { return *__b; }
|
|
|
|
};
|
|
|
|
|
2019-11-18 14:46:58 +08:00
|
|
|
template <class _Iter, bool _IsIt = __is_cpp17_input_iterator<_Iter>::value,
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
class = void>
|
|
|
|
struct __is_pathable_iter : false_type {};
|
|
|
|
|
|
|
|
template <class _Iter>
|
|
|
|
struct __is_pathable_iter<
|
|
|
|
_Iter, true,
|
|
|
|
_Void<typename __can_convert_char<
|
|
|
|
typename iterator_traits<_Iter>::value_type>::__char_type> >
|
|
|
|
: __can_convert_char<typename iterator_traits<_Iter>::value_type> {
|
|
|
|
using _ECharT = typename iterator_traits<_Iter>::value_type;
|
|
|
|
using _Base = __can_convert_char<_ECharT>;
|
|
|
|
|
|
|
|
static _Iter __range_begin(_Iter __b) { return __b; }
|
2020-10-27 17:46:06 +08:00
|
|
|
static _NullSentinel __range_end(_Iter) { return _NullSentinel{}; }
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
|
|
|
|
static _ECharT __first_or_null(_Iter __b) { return *__b; }
|
|
|
|
};
|
|
|
|
|
|
|
|
template <class _Tp, bool _IsStringT = __is_pathable_string<_Tp>::value,
|
|
|
|
bool _IsCharIterT = __is_pathable_char_array<_Tp>::value,
|
|
|
|
bool _IsIterT = !_IsCharIterT && __is_pathable_iter<_Tp>::value>
|
|
|
|
struct __is_pathable : false_type {
|
|
|
|
static_assert(!_IsStringT && !_IsCharIterT && !_IsIterT, "Must all be false");
|
|
|
|
};
|
|
|
|
|
|
|
|
template <class _Tp>
|
|
|
|
struct __is_pathable<_Tp, true, false, false> : __is_pathable_string<_Tp> {};
|
|
|
|
|
|
|
|
template <class _Tp>
|
|
|
|
struct __is_pathable<_Tp, false, true, false> : __is_pathable_char_array<_Tp> {
|
|
|
|
};
|
|
|
|
|
|
|
|
template <class _Tp>
|
|
|
|
struct __is_pathable<_Tp, false, false, true> : __is_pathable_iter<_Tp> {};
|
|
|
|
|
2020-10-27 19:09:08 +08:00
|
|
|
#if defined(_LIBCPP_WIN32API)
|
|
|
|
typedef wstring __path_string;
|
|
|
|
typedef wchar_t __path_value;
|
|
|
|
#else
|
|
|
|
typedef string __path_string;
|
|
|
|
typedef char __path_value;
|
|
|
|
#endif
|
|
|
|
|
2020-10-27 19:30:34 +08:00
|
|
|
#if defined(_LIBCPP_WIN32API)
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
size_t __wide_to_char(const wstring&, char*, size_t);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
size_t __char_to_wide(const string&, wchar_t*, size_t);
|
|
|
|
#endif
|
|
|
|
|
2020-10-10 03:31:05 +08:00
|
|
|
template <class _ECharT>
|
|
|
|
struct _PathCVT;
|
|
|
|
|
|
|
|
#if !defined(_LIBCPP_HAS_NO_LOCALIZATION)
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
template <class _ECharT>
|
|
|
|
struct _PathCVT {
|
|
|
|
static_assert(__can_convert_char<_ECharT>::value,
|
|
|
|
"Char type not convertible");
|
|
|
|
|
|
|
|
typedef __narrow_to_utf8<sizeof(_ECharT) * __CHAR_BIT__> _Narrower;
|
2020-10-27 19:09:08 +08:00
|
|
|
#if defined(_LIBCPP_WIN32API)
|
|
|
|
typedef __widen_from_utf8<sizeof(wchar_t) * __CHAR_BIT__> _Widener;
|
|
|
|
#endif
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
|
2020-10-27 19:09:08 +08:00
|
|
|
static void __append_range(__path_string& __dest, _ECharT const* __b,
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
_ECharT const* __e) {
|
2020-10-27 19:09:08 +08:00
|
|
|
#if defined(_LIBCPP_WIN32API)
|
|
|
|
string __utf8;
|
|
|
|
_Narrower()(back_inserter(__utf8), __b, __e);
|
|
|
|
_Widener()(back_inserter(__dest), __utf8.data(), __utf8.data() + __utf8.size());
|
|
|
|
#else
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
_Narrower()(back_inserter(__dest), __b, __e);
|
2020-10-27 19:09:08 +08:00
|
|
|
#endif
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
template <class _Iter>
|
2020-10-27 19:09:08 +08:00
|
|
|
static void __append_range(__path_string& __dest, _Iter __b, _Iter __e) {
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
static_assert(!is_same<_Iter, _ECharT*>::value, "Call const overload");
|
|
|
|
if (__b == __e)
|
|
|
|
return;
|
|
|
|
basic_string<_ECharT> __tmp(__b, __e);
|
2020-10-27 19:09:08 +08:00
|
|
|
#if defined(_LIBCPP_WIN32API)
|
|
|
|
string __utf8;
|
|
|
|
_Narrower()(back_inserter(__utf8), __tmp.data(),
|
|
|
|
__tmp.data() + __tmp.length());
|
|
|
|
_Widener()(back_inserter(__dest), __utf8.data(), __utf8.data() + __utf8.size());
|
|
|
|
#else
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
_Narrower()(back_inserter(__dest), __tmp.data(),
|
|
|
|
__tmp.data() + __tmp.length());
|
2020-10-27 19:09:08 +08:00
|
|
|
#endif
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
template <class _Iter>
|
2020-10-27 19:09:08 +08:00
|
|
|
static void __append_range(__path_string& __dest, _Iter __b, _NullSentinel) {
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
static_assert(!is_same<_Iter, _ECharT*>::value, "Call const overload");
|
2020-10-27 17:46:06 +08:00
|
|
|
const _ECharT __sentinel = _ECharT{};
|
|
|
|
if (*__b == __sentinel)
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
return;
|
|
|
|
basic_string<_ECharT> __tmp;
|
2020-10-27 17:46:06 +08:00
|
|
|
for (; *__b != __sentinel; ++__b)
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
__tmp.push_back(*__b);
|
2020-10-27 19:09:08 +08:00
|
|
|
#if defined(_LIBCPP_WIN32API)
|
|
|
|
string __utf8;
|
|
|
|
_Narrower()(back_inserter(__utf8), __tmp.data(),
|
|
|
|
__tmp.data() + __tmp.length());
|
|
|
|
_Widener()(back_inserter(__dest), __utf8.data(), __utf8.data() + __utf8.size());
|
|
|
|
#else
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
_Narrower()(back_inserter(__dest), __tmp.data(),
|
|
|
|
__tmp.data() + __tmp.length());
|
2020-10-27 19:09:08 +08:00
|
|
|
#endif
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
template <class _Source>
|
2020-10-27 19:09:08 +08:00
|
|
|
static void __append_source(__path_string& __dest, _Source const& __s) {
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
using _Traits = __is_pathable<_Source>;
|
|
|
|
__append_range(__dest, _Traits::__range_begin(__s),
|
|
|
|
_Traits::__range_end(__s));
|
|
|
|
}
|
|
|
|
};
|
2020-10-10 03:31:05 +08:00
|
|
|
#endif // !_LIBCPP_HAS_NO_LOCALIZATION
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
|
|
|
|
template <>
|
2020-10-27 19:09:08 +08:00
|
|
|
struct _PathCVT<__path_value> {
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
|
|
|
|
template <class _Iter>
|
2019-11-18 14:46:58 +08:00
|
|
|
static typename enable_if<__is_exactly_cpp17_input_iterator<_Iter>::value>::type
|
2020-10-27 19:09:08 +08:00
|
|
|
__append_range(__path_string& __dest, _Iter __b, _Iter __e) {
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
for (; __b != __e; ++__b)
|
|
|
|
__dest.push_back(*__b);
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class _Iter>
|
2019-11-18 14:46:58 +08:00
|
|
|
static typename enable_if<__is_cpp17_forward_iterator<_Iter>::value>::type
|
2020-10-27 19:09:08 +08:00
|
|
|
__append_range(__path_string& __dest, _Iter __b, _Iter __e) {
|
[libc++] Remove the special logic for "noexcept iterators" in basic_string.
This reverts a large chunk of http://reviews.llvm.org/D15862 ,
and also fixes bugs in `insert`, `append`, and `assign`, which are now regression-tested.
(Thanks to Tim Song for pointing out the bug in `append`!)
Before this patch, we did a special dance in `append`, `assign`, and `insert`
(but not `replace`). All of these require the strong exception guarantee,
even when the user-provided InputIterator might have throwing operations.
The naive way to accomplish this is to construct a temporary string and
then append/assign/insert from the temporary; i.e., finish all the potentially
throwing and self-inspecting InputIterator operations *before* starting to
modify self. But this is slow, so we'd like to skip it when possible.
The old code (D15682) attempted to check that specific iterator operations
were nothrow: it assumed that if the iterator operations didn't throw, then
it was safe to iterate the input range multiple times and therefore it was
safe to use the fast-path non-naive version. This was wrong for two reasons:
(1) the old code checked the wrong operations (e.g. checked noexceptness of `==`,
but the code that ran used `!=`), and (2) the conversion of value_type to char
could still throw, or inspect the contents of self.
The new code is much simpler, although still much more complicated than it
really could be. We'll likely revisit this codepath at some point, but for now
this patch suffices to get it passing all the new regression tests.
The added tests all fail before this patch, and succeed afterward.
See https://quuxplusone.github.io/blog/2021/04/17/pathological-string-appends/
Differential Revision: https://reviews.llvm.org/D98573
2021-04-17 05:49:57 +08:00
|
|
|
__dest.append(__b, __e);
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
template <class _Iter>
|
2020-10-27 19:09:08 +08:00
|
|
|
static void __append_range(__path_string& __dest, _Iter __b, _NullSentinel) {
|
2020-10-27 17:46:06 +08:00
|
|
|
const char __sentinel = char{};
|
|
|
|
for (; *__b != __sentinel; ++__b)
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
__dest.push_back(*__b);
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class _Source>
|
2020-10-27 19:09:08 +08:00
|
|
|
static void __append_source(__path_string& __dest, _Source const& __s) {
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
using _Traits = __is_pathable<_Source>;
|
|
|
|
__append_range(__dest, _Traits::__range_begin(__s),
|
|
|
|
_Traits::__range_end(__s));
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2020-10-27 19:09:08 +08:00
|
|
|
#if defined(_LIBCPP_WIN32API)
|
2020-10-27 19:30:34 +08:00
|
|
|
template <>
|
|
|
|
struct _PathCVT<char> {
|
|
|
|
|
|
|
|
static void
|
|
|
|
__append_string(__path_string& __dest, const basic_string<char> &__str) {
|
|
|
|
size_t __size = __char_to_wide(__str, nullptr, 0);
|
|
|
|
size_t __pos = __dest.size();
|
|
|
|
__dest.resize(__pos + __size);
|
|
|
|
__char_to_wide(__str, const_cast<__path_value*>(__dest.data()) + __pos, __size);
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class _Iter>
|
|
|
|
static typename enable_if<__is_exactly_cpp17_input_iterator<_Iter>::value>::type
|
|
|
|
__append_range(__path_string& __dest, _Iter __b, _Iter __e) {
|
|
|
|
basic_string<char> __tmp(__b, __e);
|
|
|
|
__append_string(__dest, __tmp);
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class _Iter>
|
|
|
|
static typename enable_if<__is_cpp17_forward_iterator<_Iter>::value>::type
|
|
|
|
__append_range(__path_string& __dest, _Iter __b, _Iter __e) {
|
|
|
|
basic_string<char> __tmp(__b, __e);
|
|
|
|
__append_string(__dest, __tmp);
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class _Iter>
|
|
|
|
static void __append_range(__path_string& __dest, _Iter __b, _NullSentinel) {
|
|
|
|
const char __sentinel = char{};
|
|
|
|
basic_string<char> __tmp;
|
|
|
|
for (; *__b != __sentinel; ++__b)
|
|
|
|
__tmp.push_back(*__b);
|
|
|
|
__append_string(__dest, __tmp);
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class _Source>
|
|
|
|
static void __append_source(__path_string& __dest, _Source const& __s) {
|
|
|
|
using _Traits = __is_pathable<_Source>;
|
|
|
|
__append_range(__dest, _Traits::__range_begin(__s),
|
|
|
|
_Traits::__range_end(__s));
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2020-10-27 19:09:08 +08:00
|
|
|
template <class _ECharT>
|
|
|
|
struct _PathExport {
|
|
|
|
typedef __narrow_to_utf8<sizeof(wchar_t) * __CHAR_BIT__> _Narrower;
|
|
|
|
typedef __widen_from_utf8<sizeof(_ECharT) * __CHAR_BIT__> _Widener;
|
|
|
|
|
|
|
|
template <class _Str>
|
|
|
|
static void __append(_Str& __dest, const __path_string& __src) {
|
|
|
|
string __utf8;
|
|
|
|
_Narrower()(back_inserter(__utf8), __src.data(), __src.data() + __src.size());
|
|
|
|
_Widener()(back_inserter(__dest), __utf8.data(), __utf8.data() + __utf8.size());
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2020-10-27 19:30:34 +08:00
|
|
|
template <>
|
|
|
|
struct _PathExport<char> {
|
|
|
|
template <class _Str>
|
|
|
|
static void __append(_Str& __dest, const __path_string& __src) {
|
|
|
|
size_t __size = __wide_to_char(__src, nullptr, 0);
|
|
|
|
size_t __pos = __dest.size();
|
|
|
|
__dest.resize(__size);
|
|
|
|
__wide_to_char(__src, const_cast<char*>(__dest.data()) + __pos, __size);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2020-10-27 19:09:08 +08:00
|
|
|
template <>
|
|
|
|
struct _PathExport<wchar_t> {
|
|
|
|
template <class _Str>
|
|
|
|
static void __append(_Str& __dest, const __path_string& __src) {
|
|
|
|
__dest.append(__src.begin(), __src.end());
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
template <>
|
|
|
|
struct _PathExport<char16_t> {
|
|
|
|
template <class _Str>
|
|
|
|
static void __append(_Str& __dest, const __path_string& __src) {
|
|
|
|
__dest.append(__src.begin(), __src.end());
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2021-04-19 09:47:08 +08:00
|
|
|
#ifndef _LIBCPP_HAS_NO_CHAR8_T
|
2020-10-27 19:09:08 +08:00
|
|
|
template <>
|
|
|
|
struct _PathExport<char8_t> {
|
|
|
|
typedef __narrow_to_utf8<sizeof(wchar_t) * __CHAR_BIT__> _Narrower;
|
|
|
|
|
|
|
|
template <class _Str>
|
|
|
|
static void __append(_Str& __dest, const __path_string& __src) {
|
|
|
|
_Narrower()(back_inserter(__dest), __src.data(), __src.data() + __src.size());
|
|
|
|
}
|
|
|
|
};
|
2021-04-19 09:47:08 +08:00
|
|
|
#endif /* !_LIBCPP_HAS_NO_CHAR8_T */
|
2020-10-27 19:09:08 +08:00
|
|
|
#endif /* _LIBCPP_WIN32API */
|
|
|
|
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
class _LIBCPP_TYPE_VIS path {
|
|
|
|
template <class _SourceOrIter, class _Tp = path&>
|
|
|
|
using _EnableIfPathable =
|
|
|
|
typename enable_if<__is_pathable<_SourceOrIter>::value, _Tp>::type;
|
|
|
|
|
|
|
|
template <class _Tp>
|
|
|
|
using _SourceChar = typename __is_pathable<_Tp>::__char_type;
|
|
|
|
|
|
|
|
template <class _Tp>
|
|
|
|
using _SourceCVT = _PathCVT<_SourceChar<_Tp> >;
|
|
|
|
|
|
|
|
public:
|
2020-10-27 19:09:08 +08:00
|
|
|
#if defined(_LIBCPP_WIN32API)
|
|
|
|
typedef wchar_t value_type;
|
|
|
|
static constexpr value_type preferred_separator = L'\\';
|
|
|
|
#else
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
typedef char value_type;
|
|
|
|
static constexpr value_type preferred_separator = '/';
|
2020-10-27 19:09:08 +08:00
|
|
|
#endif
|
|
|
|
typedef basic_string<value_type> string_type;
|
|
|
|
typedef basic_string_view<value_type> __string_view;
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
|
2020-11-06 17:57:47 +08:00
|
|
|
enum _LIBCPP_ENUM_VIS format : unsigned char {
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
auto_format,
|
|
|
|
native_format,
|
|
|
|
generic_format
|
|
|
|
};
|
|
|
|
|
|
|
|
// constructors and destructor
|
|
|
|
_LIBCPP_INLINE_VISIBILITY path() noexcept {}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY path(const path& __p) : __pn_(__p.__pn_) {}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY path(path&& __p) noexcept
|
|
|
|
: __pn_(_VSTD::move(__p.__pn_)) {}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
path(string_type&& __s, format = format::auto_format) noexcept
|
|
|
|
: __pn_(_VSTD::move(__s)) {}
|
|
|
|
|
|
|
|
template <class _Source, class = _EnableIfPathable<_Source, void> >
|
|
|
|
path(const _Source& __src, format = format::auto_format) {
|
|
|
|
_SourceCVT<_Source>::__append_source(__pn_, __src);
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class _InputIt>
|
|
|
|
path(_InputIt __first, _InputIt __last, format = format::auto_format) {
|
|
|
|
typedef typename iterator_traits<_InputIt>::value_type _ItVal;
|
|
|
|
_PathCVT<_ItVal>::__append_range(__pn_, __first, __last);
|
|
|
|
}
|
|
|
|
|
2020-10-10 03:31:05 +08:00
|
|
|
#if !defined(_LIBCPP_HAS_NO_LOCALIZATION)
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
// TODO Implement locale conversions.
|
|
|
|
template <class _Source, class = _EnableIfPathable<_Source, void> >
|
|
|
|
path(const _Source& __src, const locale& __loc, format = format::auto_format);
|
|
|
|
template <class _InputIt>
|
|
|
|
path(_InputIt __first, _InputIt _last, const locale& __loc,
|
|
|
|
format = format::auto_format);
|
2020-10-10 03:31:05 +08:00
|
|
|
#endif
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
~path() = default;
|
|
|
|
|
|
|
|
// assignments
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
path& operator=(const path& __p) {
|
|
|
|
__pn_ = __p.__pn_;
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
path& operator=(path&& __p) noexcept {
|
|
|
|
__pn_ = _VSTD::move(__p.__pn_);
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
2021-02-04 05:40:41 +08:00
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
path& operator=(string_type&& __s) noexcept {
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
__pn_ = _VSTD::move(__s);
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
path& assign(string_type&& __s) noexcept {
|
|
|
|
__pn_ = _VSTD::move(__s);
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class _Source>
|
|
|
|
_LIBCPP_INLINE_VISIBILITY _EnableIfPathable<_Source>
|
|
|
|
operator=(const _Source& __src) {
|
|
|
|
return this->assign(__src);
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class _Source>
|
|
|
|
_EnableIfPathable<_Source> assign(const _Source& __src) {
|
|
|
|
__pn_.clear();
|
|
|
|
_SourceCVT<_Source>::__append_source(__pn_, __src);
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class _InputIt>
|
|
|
|
path& assign(_InputIt __first, _InputIt __last) {
|
|
|
|
typedef typename iterator_traits<_InputIt>::value_type _ItVal;
|
|
|
|
__pn_.clear();
|
|
|
|
_PathCVT<_ItVal>::__append_range(__pn_, __first, __last);
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public:
|
|
|
|
// appends
|
2020-11-04 21:59:56 +08:00
|
|
|
#if defined(_LIBCPP_WIN32API)
|
|
|
|
path& operator/=(const path& __p) {
|
|
|
|
auto __p_root_name = __p.__root_name();
|
|
|
|
auto __p_root_name_size = __p_root_name.size();
|
|
|
|
if (__p.is_absolute() ||
|
|
|
|
(!__p_root_name.empty() && __p_root_name != root_name())) {
|
|
|
|
__pn_ = __p.__pn_;
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
if (__p.has_root_directory()) {
|
|
|
|
path __root_name_str = root_name();
|
|
|
|
__pn_ = __root_name_str.native();
|
2021-03-11 19:06:08 +08:00
|
|
|
__pn_ += __string_view(__p.__pn_).substr(__p_root_name_size);
|
2020-11-04 21:59:56 +08:00
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
if (has_filename() || (!has_root_directory() && is_absolute()))
|
|
|
|
__pn_ += preferred_separator;
|
2021-03-11 19:06:08 +08:00
|
|
|
__pn_ += __string_view(__p.__pn_).substr(__p_root_name_size);
|
2020-11-04 21:59:56 +08:00
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
template <class _Source>
|
|
|
|
_LIBCPP_INLINE_VISIBILITY _EnableIfPathable<_Source>
|
|
|
|
operator/=(const _Source& __src) {
|
|
|
|
return operator/=(path(__src));
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class _Source>
|
|
|
|
_EnableIfPathable<_Source> append(const _Source& __src) {
|
|
|
|
return operator/=(path(__src));
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class _InputIt>
|
|
|
|
path& append(_InputIt __first, _InputIt __last) {
|
|
|
|
return operator/=(path(__first, __last));
|
|
|
|
}
|
|
|
|
#else
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
path& operator/=(const path& __p) {
|
|
|
|
if (__p.is_absolute()) {
|
|
|
|
__pn_ = __p.__pn_;
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
if (has_filename())
|
|
|
|
__pn_ += preferred_separator;
|
|
|
|
__pn_ += __p.native();
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
// FIXME: Use _LIBCPP_DIAGNOSE_WARNING to produce a diagnostic when __src
|
|
|
|
// is known at compile time to be "/' since the user almost certainly intended
|
|
|
|
// to append a separator instead of overwriting the path with "/"
|
|
|
|
template <class _Source>
|
|
|
|
_LIBCPP_INLINE_VISIBILITY _EnableIfPathable<_Source>
|
|
|
|
operator/=(const _Source& __src) {
|
|
|
|
return this->append(__src);
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class _Source>
|
|
|
|
_EnableIfPathable<_Source> append(const _Source& __src) {
|
|
|
|
using _Traits = __is_pathable<_Source>;
|
|
|
|
using _CVT = _PathCVT<_SourceChar<_Source> >;
|
2020-11-04 21:59:56 +08:00
|
|
|
bool __source_is_absolute = __is_separator(_Traits::__first_or_null(__src));
|
|
|
|
if (__source_is_absolute)
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
__pn_.clear();
|
|
|
|
else if (has_filename())
|
|
|
|
__pn_ += preferred_separator;
|
|
|
|
_CVT::__append_source(__pn_, __src);
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class _InputIt>
|
|
|
|
path& append(_InputIt __first, _InputIt __last) {
|
|
|
|
typedef typename iterator_traits<_InputIt>::value_type _ItVal;
|
|
|
|
static_assert(__can_convert_char<_ItVal>::value, "Must convertible");
|
|
|
|
using _CVT = _PathCVT<_ItVal>;
|
2020-11-04 21:59:56 +08:00
|
|
|
if (__first != __last && __is_separator(*__first))
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
__pn_.clear();
|
|
|
|
else if (has_filename())
|
|
|
|
__pn_ += preferred_separator;
|
|
|
|
_CVT::__append_range(__pn_, __first, __last);
|
|
|
|
return *this;
|
|
|
|
}
|
2020-11-04 21:59:56 +08:00
|
|
|
#endif
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
|
|
|
|
// concatenation
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
path& operator+=(const path& __x) {
|
|
|
|
__pn_ += __x.__pn_;
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
path& operator+=(const string_type& __x) {
|
|
|
|
__pn_ += __x;
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
path& operator+=(__string_view __x) {
|
|
|
|
__pn_ += __x;
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
path& operator+=(const value_type* __x) {
|
|
|
|
__pn_ += __x;
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
path& operator+=(value_type __x) {
|
|
|
|
__pn_ += __x;
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class _ECharT>
|
|
|
|
typename enable_if<__can_convert_char<_ECharT>::value, path&>::type
|
|
|
|
operator+=(_ECharT __x) {
|
2020-12-08 03:07:25 +08:00
|
|
|
_PathCVT<_ECharT>::__append_source(__pn_,
|
|
|
|
basic_string_view<_ECharT>(&__x, 1));
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class _Source>
|
|
|
|
_EnableIfPathable<_Source> operator+=(const _Source& __x) {
|
|
|
|
return this->concat(__x);
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class _Source>
|
|
|
|
_EnableIfPathable<_Source> concat(const _Source& __x) {
|
|
|
|
_SourceCVT<_Source>::__append_source(__pn_, __x);
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class _InputIt>
|
|
|
|
path& concat(_InputIt __first, _InputIt __last) {
|
|
|
|
typedef typename iterator_traits<_InputIt>::value_type _ItVal;
|
|
|
|
_PathCVT<_ItVal>::__append_range(__pn_, __first, __last);
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
// modifiers
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
void clear() noexcept { __pn_.clear(); }
|
|
|
|
|
2020-10-28 18:24:11 +08:00
|
|
|
path& make_preferred() {
|
|
|
|
#if defined(_LIBCPP_WIN32API)
|
|
|
|
_VSTD::replace(__pn_.begin(), __pn_.end(), L'/', L'\\');
|
|
|
|
#endif
|
|
|
|
return *this;
|
|
|
|
}
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
path& remove_filename() {
|
|
|
|
auto __fname = __filename();
|
|
|
|
if (!__fname.empty())
|
|
|
|
__pn_.erase(__fname.data() - __pn_.data());
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
path& replace_filename(const path& __replacement) {
|
|
|
|
remove_filename();
|
|
|
|
return (*this /= __replacement);
|
|
|
|
}
|
|
|
|
|
|
|
|
path& replace_extension(const path& __replacement = path());
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
void swap(path& __rhs) noexcept { __pn_.swap(__rhs.__pn_); }
|
|
|
|
|
|
|
|
// private helper to allow reserving memory in the path
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
void __reserve(size_t __s) { __pn_.reserve(__s); }
|
|
|
|
|
|
|
|
// native format observers
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
const string_type& native() const noexcept { return __pn_; }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
const value_type* c_str() const noexcept { return __pn_.c_str(); }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY operator string_type() const { return __pn_; }
|
|
|
|
|
2020-10-27 19:09:08 +08:00
|
|
|
#if defined(_LIBCPP_WIN32API)
|
|
|
|
_LIBCPP_INLINE_VISIBILITY _VSTD::wstring wstring() const { return __pn_; }
|
|
|
|
|
2020-11-09 17:45:13 +08:00
|
|
|
_VSTD::wstring generic_wstring() const {
|
|
|
|
_VSTD::wstring __s;
|
|
|
|
__s.resize(__pn_.size());
|
|
|
|
_VSTD::replace_copy(__pn_.begin(), __pn_.end(), __s.begin(), '\\', '/');
|
|
|
|
return __s;
|
|
|
|
}
|
2020-10-27 19:09:08 +08:00
|
|
|
|
|
|
|
#if !defined(_LIBCPP_HAS_NO_LOCALIZATION)
|
|
|
|
template <class _ECharT, class _Traits = char_traits<_ECharT>,
|
|
|
|
class _Allocator = allocator<_ECharT> >
|
|
|
|
basic_string<_ECharT, _Traits, _Allocator>
|
|
|
|
string(const _Allocator& __a = _Allocator()) const {
|
|
|
|
using _Str = basic_string<_ECharT, _Traits, _Allocator>;
|
|
|
|
_Str __s(__a);
|
|
|
|
__s.reserve(__pn_.size());
|
|
|
|
_PathExport<_ECharT>::__append(__s, __pn_);
|
|
|
|
return __s;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY _VSTD::string string() const {
|
|
|
|
return string<char>();
|
|
|
|
}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY __u8_string u8string() const {
|
2020-10-27 19:30:34 +08:00
|
|
|
using _CVT = __narrow_to_utf8<sizeof(wchar_t) * __CHAR_BIT__>;
|
|
|
|
__u8_string __s;
|
|
|
|
__s.reserve(__pn_.size());
|
|
|
|
_CVT()(back_inserter(__s), __pn_.data(), __pn_.data() + __pn_.size());
|
|
|
|
return __s;
|
2020-10-27 19:09:08 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY _VSTD::u16string u16string() const {
|
|
|
|
return string<char16_t>();
|
|
|
|
}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY _VSTD::u32string u32string() const {
|
|
|
|
return string<char32_t>();
|
|
|
|
}
|
|
|
|
|
|
|
|
// generic format observers
|
|
|
|
template <class _ECharT, class _Traits = char_traits<_ECharT>,
|
|
|
|
class _Allocator = allocator<_ECharT> >
|
|
|
|
basic_string<_ECharT, _Traits, _Allocator>
|
|
|
|
generic_string(const _Allocator& __a = _Allocator()) const {
|
2020-11-09 17:45:13 +08:00
|
|
|
using _Str = basic_string<_ECharT, _Traits, _Allocator>;
|
|
|
|
_Str __s = string<_ECharT, _Traits, _Allocator>(__a);
|
|
|
|
// Note: This (and generic_u8string below) is slightly suboptimal as
|
|
|
|
// it iterates twice over the string; once to convert it to the right
|
|
|
|
// character type, and once to replace path delimiters.
|
|
|
|
_VSTD::replace(__s.begin(), __s.end(),
|
|
|
|
static_cast<_ECharT>('\\'), static_cast<_ECharT>('/'));
|
|
|
|
return __s;
|
2020-10-27 19:09:08 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
_VSTD::string generic_string() const { return generic_string<char>(); }
|
|
|
|
_VSTD::u16string generic_u16string() const { return generic_string<char16_t>(); }
|
|
|
|
_VSTD::u32string generic_u32string() const { return generic_string<char32_t>(); }
|
2020-11-09 17:45:13 +08:00
|
|
|
__u8_string generic_u8string() const {
|
|
|
|
__u8_string __s = u8string();
|
|
|
|
_VSTD::replace(__s.begin(), __s.end(), '\\', '/');
|
|
|
|
return __s;
|
|
|
|
}
|
2020-10-27 19:09:08 +08:00
|
|
|
#endif /* !_LIBCPP_HAS_NO_LOCALIZATION */
|
|
|
|
#else /* _LIBCPP_WIN32API */
|
|
|
|
|
[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.
I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:
- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.
- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.
- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.
In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.
Differential Revision: https://reviews.llvm.org/D92250
2020-11-28 00:02:06 +08:00
|
|
|
_LIBCPP_INLINE_VISIBILITY _VSTD::string string() const { return __pn_; }
|
2021-04-19 09:47:08 +08:00
|
|
|
#ifndef _LIBCPP_HAS_NO_CHAR8_T
|
2020-10-26 19:18:46 +08:00
|
|
|
_LIBCPP_INLINE_VISIBILITY _VSTD::u8string u8string() const { return _VSTD::u8string(__pn_.begin(), __pn_.end()); }
|
|
|
|
#else
|
[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.
I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:
- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.
- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.
- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.
In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.
Differential Revision: https://reviews.llvm.org/D92250
2020-11-28 00:02:06 +08:00
|
|
|
_LIBCPP_INLINE_VISIBILITY _VSTD::string u8string() const { return __pn_; }
|
2020-10-26 19:18:46 +08:00
|
|
|
#endif
|
2020-10-10 03:31:05 +08:00
|
|
|
|
|
|
|
#if !defined(_LIBCPP_HAS_NO_LOCALIZATION)
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
template <class _ECharT, class _Traits = char_traits<_ECharT>,
|
|
|
|
class _Allocator = allocator<_ECharT> >
|
|
|
|
basic_string<_ECharT, _Traits, _Allocator>
|
|
|
|
string(const _Allocator& __a = _Allocator()) const {
|
|
|
|
using _CVT = __widen_from_utf8<sizeof(_ECharT) * __CHAR_BIT__>;
|
|
|
|
using _Str = basic_string<_ECharT, _Traits, _Allocator>;
|
|
|
|
_Str __s(__a);
|
|
|
|
__s.reserve(__pn_.size());
|
|
|
|
_CVT()(back_inserter(__s), __pn_.data(), __pn_.data() + __pn_.size());
|
|
|
|
return __s;
|
|
|
|
}
|
|
|
|
|
[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.
I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:
- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.
- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.
- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.
In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.
Differential Revision: https://reviews.llvm.org/D92250
2020-11-28 00:02:06 +08:00
|
|
|
_LIBCPP_INLINE_VISIBILITY _VSTD::wstring wstring() const {
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
return string<wchar_t>();
|
|
|
|
}
|
[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.
I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:
- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.
- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.
- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.
In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.
Differential Revision: https://reviews.llvm.org/D92250
2020-11-28 00:02:06 +08:00
|
|
|
_LIBCPP_INLINE_VISIBILITY _VSTD::u16string u16string() const {
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
return string<char16_t>();
|
|
|
|
}
|
[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.
I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:
- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.
- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.
- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.
In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.
Differential Revision: https://reviews.llvm.org/D92250
2020-11-28 00:02:06 +08:00
|
|
|
_LIBCPP_INLINE_VISIBILITY _VSTD::u32string u32string() const {
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
return string<char32_t>();
|
|
|
|
}
|
2020-10-27 19:09:08 +08:00
|
|
|
#endif /* !_LIBCPP_HAS_NO_LOCALIZATION */
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
|
|
|
|
// generic format observers
|
[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.
I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:
- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.
- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.
- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.
In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.
Differential Revision: https://reviews.llvm.org/D92250
2020-11-28 00:02:06 +08:00
|
|
|
_VSTD::string generic_string() const { return __pn_; }
|
2021-04-19 09:47:08 +08:00
|
|
|
#ifndef _LIBCPP_HAS_NO_CHAR8_T
|
2020-10-26 19:18:46 +08:00
|
|
|
_VSTD::u8string generic_u8string() const { return _VSTD::u8string(__pn_.begin(), __pn_.end()); }
|
|
|
|
#else
|
[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.
I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:
- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.
- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.
- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.
In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.
Differential Revision: https://reviews.llvm.org/D92250
2020-11-28 00:02:06 +08:00
|
|
|
_VSTD::string generic_u8string() const { return __pn_; }
|
2020-10-26 19:18:46 +08:00
|
|
|
#endif
|
2020-10-10 03:31:05 +08:00
|
|
|
|
|
|
|
#if !defined(_LIBCPP_HAS_NO_LOCALIZATION)
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
template <class _ECharT, class _Traits = char_traits<_ECharT>,
|
|
|
|
class _Allocator = allocator<_ECharT> >
|
|
|
|
basic_string<_ECharT, _Traits, _Allocator>
|
|
|
|
generic_string(const _Allocator& __a = _Allocator()) const {
|
|
|
|
return string<_ECharT, _Traits, _Allocator>(__a);
|
|
|
|
}
|
|
|
|
|
[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.
I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:
- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.
- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.
- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.
In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.
Differential Revision: https://reviews.llvm.org/D92250
2020-11-28 00:02:06 +08:00
|
|
|
_VSTD::wstring generic_wstring() const { return string<wchar_t>(); }
|
|
|
|
_VSTD::u16string generic_u16string() const { return string<char16_t>(); }
|
|
|
|
_VSTD::u32string generic_u32string() const { return string<char32_t>(); }
|
2020-10-27 19:09:08 +08:00
|
|
|
#endif /* !_LIBCPP_HAS_NO_LOCALIZATION */
|
|
|
|
#endif /* !_LIBCPP_WIN32API */
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
|
|
|
|
private:
|
|
|
|
int __compare(__string_view) const;
|
|
|
|
__string_view __root_name() const;
|
|
|
|
__string_view __root_directory() const;
|
|
|
|
__string_view __root_path_raw() const;
|
|
|
|
__string_view __relative_path() const;
|
|
|
|
__string_view __parent_path() const;
|
|
|
|
__string_view __filename() const;
|
|
|
|
__string_view __stem() const;
|
|
|
|
__string_view __extension() const;
|
|
|
|
|
|
|
|
public:
|
|
|
|
// compare
|
|
|
|
_LIBCPP_INLINE_VISIBILITY int compare(const path& __p) const noexcept {
|
|
|
|
return __compare(__p.__pn_);
|
|
|
|
}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY int compare(const string_type& __s) const {
|
|
|
|
return __compare(__s);
|
|
|
|
}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY int compare(__string_view __s) const {
|
|
|
|
return __compare(__s);
|
|
|
|
}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY int compare(const value_type* __s) const {
|
|
|
|
return __compare(__s);
|
|
|
|
}
|
|
|
|
|
|
|
|
// decomposition
|
|
|
|
_LIBCPP_INLINE_VISIBILITY path root_name() const {
|
|
|
|
return string_type(__root_name());
|
|
|
|
}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY path root_directory() const {
|
|
|
|
return string_type(__root_directory());
|
|
|
|
}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY path root_path() const {
|
2020-11-04 21:59:56 +08:00
|
|
|
#if defined(_LIBCPP_WIN32API)
|
|
|
|
return string_type(__root_path_raw());
|
|
|
|
#else
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
return root_name().append(string_type(__root_directory()));
|
2020-11-04 21:59:56 +08:00
|
|
|
#endif
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY path relative_path() const {
|
|
|
|
return string_type(__relative_path());
|
|
|
|
}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY path parent_path() const {
|
|
|
|
return string_type(__parent_path());
|
|
|
|
}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY path filename() const {
|
|
|
|
return string_type(__filename());
|
|
|
|
}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY path stem() const { return string_type(__stem()); }
|
|
|
|
_LIBCPP_INLINE_VISIBILITY path extension() const {
|
|
|
|
return string_type(__extension());
|
|
|
|
}
|
|
|
|
|
|
|
|
// query
|
|
|
|
_LIBCPP_NODISCARD_AFTER_CXX17 _LIBCPP_INLINE_VISIBILITY bool
|
|
|
|
empty() const noexcept {
|
|
|
|
return __pn_.empty();
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY bool has_root_name() const {
|
|
|
|
return !__root_name().empty();
|
|
|
|
}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY bool has_root_directory() const {
|
|
|
|
return !__root_directory().empty();
|
|
|
|
}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY bool has_root_path() const {
|
|
|
|
return !__root_path_raw().empty();
|
|
|
|
}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY bool has_relative_path() const {
|
|
|
|
return !__relative_path().empty();
|
|
|
|
}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY bool has_parent_path() const {
|
|
|
|
return !__parent_path().empty();
|
|
|
|
}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY bool has_filename() const {
|
|
|
|
return !__filename().empty();
|
|
|
|
}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY bool has_stem() const { return !__stem().empty(); }
|
|
|
|
_LIBCPP_INLINE_VISIBILITY bool has_extension() const {
|
|
|
|
return !__extension().empty();
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY bool is_absolute() const {
|
2020-11-02 05:39:03 +08:00
|
|
|
#if defined(_LIBCPP_WIN32API)
|
|
|
|
__string_view __root_name_str = __root_name();
|
|
|
|
__string_view __root_dir = __root_directory();
|
|
|
|
if (__root_name_str.size() == 2 && __root_name_str[1] == ':') {
|
|
|
|
// A drive letter with no root directory is relative, e.g. x:example.
|
|
|
|
return !__root_dir.empty();
|
|
|
|
}
|
|
|
|
// If no root name, it's relative, e.g. \example is relative to the current drive
|
|
|
|
if (__root_name_str.empty())
|
|
|
|
return false;
|
|
|
|
if (__root_name_str.size() < 3)
|
|
|
|
return false;
|
|
|
|
// A server root name, like \\server, is always absolute
|
|
|
|
if (__root_name_str[0] != '/' && __root_name_str[0] != '\\')
|
|
|
|
return false;
|
|
|
|
if (__root_name_str[1] != '/' && __root_name_str[1] != '\\')
|
|
|
|
return false;
|
|
|
|
// Seems to be a server root name
|
|
|
|
return true;
|
|
|
|
#else
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
return has_root_directory();
|
2020-11-02 05:39:03 +08:00
|
|
|
#endif
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY bool is_relative() const { return !is_absolute(); }
|
|
|
|
|
|
|
|
// relative paths
|
|
|
|
path lexically_normal() const;
|
|
|
|
path lexically_relative(const path& __base) const;
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY path lexically_proximate(const path& __base) const {
|
|
|
|
path __result = this->lexically_relative(__base);
|
|
|
|
if (__result.native().empty())
|
|
|
|
return *this;
|
|
|
|
return __result;
|
|
|
|
}
|
|
|
|
|
|
|
|
// iterators
|
|
|
|
class _LIBCPP_TYPE_VIS iterator;
|
|
|
|
typedef iterator const_iterator;
|
|
|
|
|
|
|
|
iterator begin() const;
|
|
|
|
iterator end() const;
|
|
|
|
|
2020-10-10 03:31:05 +08:00
|
|
|
#if !defined(_LIBCPP_HAS_NO_LOCALIZATION)
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
template <class _CharT, class _Traits>
|
|
|
|
_LIBCPP_INLINE_VISIBILITY friend
|
2020-10-27 19:09:08 +08:00
|
|
|
typename enable_if<is_same<_CharT, value_type>::value &&
|
|
|
|
is_same<_Traits, char_traits<value_type> >::value,
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
basic_ostream<_CharT, _Traits>&>::type
|
|
|
|
operator<<(basic_ostream<_CharT, _Traits>& __os, const path& __p) {
|
[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.
I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:
- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.
- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.
- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.
In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.
Differential Revision: https://reviews.llvm.org/D92250
2020-11-28 00:02:06 +08:00
|
|
|
__os << _VSTD::__quoted(__p.native());
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
return __os;
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class _CharT, class _Traits>
|
|
|
|
_LIBCPP_INLINE_VISIBILITY friend
|
2020-10-27 19:09:08 +08:00
|
|
|
typename enable_if<!is_same<_CharT, value_type>::value ||
|
|
|
|
!is_same<_Traits, char_traits<value_type> >::value,
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
basic_ostream<_CharT, _Traits>&>::type
|
|
|
|
operator<<(basic_ostream<_CharT, _Traits>& __os, const path& __p) {
|
[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.
I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:
- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.
- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.
- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.
In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.
Differential Revision: https://reviews.llvm.org/D92250
2020-11-28 00:02:06 +08:00
|
|
|
__os << _VSTD::__quoted(__p.string<_CharT, _Traits>());
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
return __os;
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class _CharT, class _Traits>
|
|
|
|
_LIBCPP_INLINE_VISIBILITY friend basic_istream<_CharT, _Traits>&
|
|
|
|
operator>>(basic_istream<_CharT, _Traits>& __is, path& __p) {
|
|
|
|
basic_string<_CharT, _Traits> __tmp;
|
|
|
|
__is >> __quoted(__tmp);
|
|
|
|
__p = __tmp;
|
|
|
|
return __is;
|
|
|
|
}
|
2020-10-10 03:31:05 +08:00
|
|
|
#endif // !_LIBCPP_HAS_NO_LOCALIZATION
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
|
2018-12-21 12:09:01 +08:00
|
|
|
friend _LIBCPP_INLINE_VISIBILITY bool operator==(const path& __lhs, const path& __rhs) noexcept {
|
|
|
|
return __lhs.compare(__rhs) == 0;
|
|
|
|
}
|
|
|
|
friend _LIBCPP_INLINE_VISIBILITY bool operator!=(const path& __lhs, const path& __rhs) noexcept {
|
|
|
|
return __lhs.compare(__rhs) != 0;
|
|
|
|
}
|
|
|
|
friend _LIBCPP_INLINE_VISIBILITY bool operator<(const path& __lhs, const path& __rhs) noexcept {
|
|
|
|
return __lhs.compare(__rhs) < 0;
|
|
|
|
}
|
|
|
|
friend _LIBCPP_INLINE_VISIBILITY bool operator<=(const path& __lhs, const path& __rhs) noexcept {
|
|
|
|
return __lhs.compare(__rhs) <= 0;
|
|
|
|
}
|
|
|
|
friend _LIBCPP_INLINE_VISIBILITY bool operator>(const path& __lhs, const path& __rhs) noexcept {
|
|
|
|
return __lhs.compare(__rhs) > 0;
|
|
|
|
}
|
|
|
|
friend _LIBCPP_INLINE_VISIBILITY bool operator>=(const path& __lhs, const path& __rhs) noexcept {
|
|
|
|
return __lhs.compare(__rhs) >= 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
friend _LIBCPP_INLINE_VISIBILITY path operator/(const path& __lhs,
|
|
|
|
const path& __rhs) {
|
|
|
|
path __result(__lhs);
|
|
|
|
__result /= __rhs;
|
|
|
|
return __result;
|
|
|
|
}
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
private:
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY path&
|
|
|
|
__assign_view(__string_view const& __s) noexcept {
|
|
|
|
__pn_ = string_type(__s);
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
string_type __pn_;
|
|
|
|
};
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void swap(path& __lhs, path& __rhs) noexcept {
|
|
|
|
__lhs.swap(__rhs);
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
size_t hash_value(const path& __p) noexcept;
|
|
|
|
|
|
|
|
template <class _InputIt>
|
2020-10-26 19:18:46 +08:00
|
|
|
_LIBCPP_INLINE_VISIBILITY _LIBCPP_DEPRECATED_WITH_CHAR8_T
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
typename enable_if<__is_pathable<_InputIt>::value, path>::type
|
|
|
|
u8path(_InputIt __f, _InputIt __l) {
|
|
|
|
static_assert(
|
2021-04-19 09:47:08 +08:00
|
|
|
#ifndef _LIBCPP_HAS_NO_CHAR8_T
|
2020-10-26 19:18:46 +08:00
|
|
|
is_same<typename __is_pathable<_InputIt>::__char_type, char8_t>::value ||
|
|
|
|
#endif
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
is_same<typename __is_pathable<_InputIt>::__char_type, char>::value,
|
2020-10-26 19:18:46 +08:00
|
|
|
"u8path(Iter, Iter) requires Iter have a value_type of type 'char'"
|
2020-12-15 15:15:37 +08:00
|
|
|
" or 'char8_t'");
|
2020-10-27 19:30:34 +08:00
|
|
|
#if defined(_LIBCPP_WIN32API)
|
|
|
|
string __tmp(__f, __l);
|
|
|
|
using _CVT = __widen_from_utf8<sizeof(wchar_t) * __CHAR_BIT__>;
|
|
|
|
_VSTD::wstring __w;
|
|
|
|
__w.reserve(__tmp.size());
|
|
|
|
_CVT()(back_inserter(__w), __tmp.data(), __tmp.data() + __tmp.size());
|
|
|
|
return path(__w);
|
|
|
|
#else
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
return path(__f, __l);
|
2020-10-27 19:30:34 +08:00
|
|
|
#endif /* !_LIBCPP_WIN32API */
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
}
|
|
|
|
|
2020-10-27 19:30:34 +08:00
|
|
|
#if defined(_LIBCPP_WIN32API)
|
|
|
|
template <class _InputIt>
|
|
|
|
_LIBCPP_INLINE_VISIBILITY _LIBCPP_DEPRECATED_WITH_CHAR8_T
|
|
|
|
typename enable_if<__is_pathable<_InputIt>::value, path>::type
|
|
|
|
u8path(_InputIt __f, _NullSentinel) {
|
|
|
|
static_assert(
|
2021-04-19 09:47:08 +08:00
|
|
|
#ifndef _LIBCPP_HAS_NO_CHAR8_T
|
2020-10-27 19:30:34 +08:00
|
|
|
is_same<typename __is_pathable<_InputIt>::__char_type, char8_t>::value ||
|
|
|
|
#endif
|
|
|
|
is_same<typename __is_pathable<_InputIt>::__char_type, char>::value,
|
|
|
|
"u8path(Iter, Iter) requires Iter have a value_type of type 'char'"
|
|
|
|
" or 'char8_t'");
|
|
|
|
string __tmp;
|
|
|
|
const char __sentinel = char{};
|
|
|
|
for (; *__f != __sentinel; ++__f)
|
|
|
|
__tmp.push_back(*__f);
|
|
|
|
using _CVT = __widen_from_utf8<sizeof(wchar_t) * __CHAR_BIT__>;
|
|
|
|
_VSTD::wstring __w;
|
|
|
|
__w.reserve(__tmp.size());
|
|
|
|
_CVT()(back_inserter(__w), __tmp.data(), __tmp.data() + __tmp.size());
|
|
|
|
return path(__w);
|
|
|
|
}
|
|
|
|
#endif /* _LIBCPP_WIN32API */
|
|
|
|
|
2020-11-05 06:21:30 +08:00
|
|
|
template <class _Source>
|
|
|
|
_LIBCPP_INLINE_VISIBILITY _LIBCPP_DEPRECATED_WITH_CHAR8_T
|
|
|
|
typename enable_if<__is_pathable<_Source>::value, path>::type
|
|
|
|
u8path(const _Source& __s) {
|
|
|
|
static_assert(
|
2021-04-19 09:47:08 +08:00
|
|
|
#ifndef _LIBCPP_HAS_NO_CHAR8_T
|
2020-11-05 06:21:30 +08:00
|
|
|
is_same<typename __is_pathable<_Source>::__char_type, char8_t>::value ||
|
|
|
|
#endif
|
|
|
|
is_same<typename __is_pathable<_Source>::__char_type, char>::value,
|
|
|
|
"u8path(Source const&) requires Source have a character type of type "
|
|
|
|
"'char' or 'char8_t'");
|
2020-10-27 19:30:34 +08:00
|
|
|
#if defined(_LIBCPP_WIN32API)
|
|
|
|
using _Traits = __is_pathable<_Source>;
|
2021-01-16 01:59:56 +08:00
|
|
|
return u8path(_VSTD::__unwrap_iter(_Traits::__range_begin(__s)), _VSTD::__unwrap_iter(_Traits::__range_end(__s)));
|
2020-10-27 19:30:34 +08:00
|
|
|
#else
|
2020-11-05 06:21:30 +08:00
|
|
|
return path(__s);
|
2020-10-27 19:30:34 +08:00
|
|
|
#endif
|
2020-11-05 06:21:30 +08:00
|
|
|
}
|
|
|
|
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
class _LIBCPP_TYPE_VIS path::iterator {
|
|
|
|
public:
|
|
|
|
enum _ParserState : unsigned char {
|
|
|
|
_Singular,
|
|
|
|
_BeforeBegin,
|
|
|
|
_InRootName,
|
|
|
|
_InRootDir,
|
|
|
|
_InFilenames,
|
|
|
|
_InTrailingSep,
|
|
|
|
_AtEnd
|
|
|
|
};
|
|
|
|
|
|
|
|
public:
|
|
|
|
typedef bidirectional_iterator_tag iterator_category;
|
|
|
|
|
|
|
|
typedef path value_type;
|
[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.
I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:
- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.
- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.
- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.
In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.
Differential Revision: https://reviews.llvm.org/D92250
2020-11-28 00:02:06 +08:00
|
|
|
typedef ptrdiff_t difference_type;
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
typedef const path* pointer;
|
|
|
|
typedef const path& reference;
|
|
|
|
|
|
|
|
typedef void
|
|
|
|
__stashing_iterator_tag; // See reverse_iterator and __is_stashing_iterator
|
|
|
|
|
|
|
|
public:
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
iterator()
|
|
|
|
: __stashed_elem_(), __path_ptr_(nullptr), __entry_(),
|
|
|
|
__state_(_Singular) {}
|
|
|
|
|
|
|
|
iterator(const iterator&) = default;
|
|
|
|
~iterator() = default;
|
|
|
|
|
|
|
|
iterator& operator=(const iterator&) = default;
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
reference operator*() const { return __stashed_elem_; }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
pointer operator->() const { return &__stashed_elem_; }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
iterator& operator++() {
|
|
|
|
_LIBCPP_ASSERT(__state_ != _Singular,
|
|
|
|
"attempting to increment a singular iterator");
|
|
|
|
_LIBCPP_ASSERT(__state_ != _AtEnd,
|
|
|
|
"attempting to increment the end iterator");
|
|
|
|
return __increment();
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
iterator operator++(int) {
|
|
|
|
iterator __it(*this);
|
|
|
|
this->operator++();
|
|
|
|
return __it;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
iterator& operator--() {
|
|
|
|
_LIBCPP_ASSERT(__state_ != _Singular,
|
|
|
|
"attempting to decrement a singular iterator");
|
|
|
|
_LIBCPP_ASSERT(__entry_.data() != __path_ptr_->native().data(),
|
|
|
|
"attempting to decrement the begin iterator");
|
|
|
|
return __decrement();
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
iterator operator--(int) {
|
|
|
|
iterator __it(*this);
|
|
|
|
this->operator--();
|
|
|
|
return __it;
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
friend class path;
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY friend bool operator==(const iterator&,
|
|
|
|
const iterator&);
|
|
|
|
|
|
|
|
iterator& __increment();
|
|
|
|
iterator& __decrement();
|
|
|
|
|
|
|
|
path __stashed_elem_;
|
|
|
|
const path* __path_ptr_;
|
|
|
|
path::__string_view __entry_;
|
|
|
|
_ParserState __state_;
|
|
|
|
};
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool operator==(const path::iterator& __lhs,
|
|
|
|
const path::iterator& __rhs) {
|
|
|
|
return __lhs.__path_ptr_ == __rhs.__path_ptr_ &&
|
|
|
|
__lhs.__entry_.data() == __rhs.__entry_.data();
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool operator!=(const path::iterator& __lhs,
|
|
|
|
const path::iterator& __rhs) {
|
|
|
|
return !(__lhs == __rhs);
|
|
|
|
}
|
|
|
|
|
2019-03-21 05:18:14 +08:00
|
|
|
// TODO(ldionne): We need to pop the pragma and push it again after
|
|
|
|
// filesystem_error to work around PR41078.
|
|
|
|
_LIBCPP_AVAILABILITY_FILESYSTEM_POP
|
|
|
|
|
|
|
|
class _LIBCPP_AVAILABILITY_FILESYSTEM _LIBCPP_EXCEPTION_ABI filesystem_error : public system_error {
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
public:
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
filesystem_error(const string& __what, error_code __ec)
|
|
|
|
: system_error(__ec, __what),
|
|
|
|
__storage_(make_shared<_Storage>(path(), path())) {
|
|
|
|
__create_what(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
filesystem_error(const string& __what, const path& __p1, error_code __ec)
|
|
|
|
: system_error(__ec, __what),
|
|
|
|
__storage_(make_shared<_Storage>(__p1, path())) {
|
|
|
|
__create_what(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
filesystem_error(const string& __what, const path& __p1, const path& __p2,
|
|
|
|
error_code __ec)
|
|
|
|
: system_error(__ec, __what),
|
|
|
|
__storage_(make_shared<_Storage>(__p1, __p2)) {
|
|
|
|
__create_what(2);
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
const path& path1() const noexcept { return __storage_->__p1_; }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
const path& path2() const noexcept { return __storage_->__p2_; }
|
|
|
|
|
2020-03-14 02:36:26 +08:00
|
|
|
filesystem_error(const filesystem_error&) = default;
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
~filesystem_error() override; // key function
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
const char* what() const noexcept override {
|
|
|
|
return __storage_->__what_.c_str();
|
|
|
|
}
|
|
|
|
|
|
|
|
void __create_what(int __num_paths);
|
|
|
|
|
|
|
|
private:
|
2019-03-20 01:47:53 +08:00
|
|
|
struct _LIBCPP_HIDDEN _Storage {
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
_Storage(const path& __p1, const path& __p2) : __p1_(__p1), __p2_(__p2) {}
|
|
|
|
|
|
|
|
path __p1_;
|
|
|
|
path __p2_;
|
|
|
|
string __what_;
|
|
|
|
};
|
|
|
|
shared_ptr<_Storage> __storage_;
|
|
|
|
};
|
|
|
|
|
2019-03-21 05:18:14 +08:00
|
|
|
_LIBCPP_AVAILABILITY_FILESYSTEM_PUSH
|
|
|
|
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
template <class... _Args>
|
|
|
|
_LIBCPP_NORETURN inline _LIBCPP_INLINE_VISIBILITY
|
|
|
|
#ifndef _LIBCPP_NO_EXCEPTIONS
|
2019-02-05 23:46:52 +08:00
|
|
|
void __throw_filesystem_error(_Args&&... __args) {
|
[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.
I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:
- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.
- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.
- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.
In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.
Differential Revision: https://reviews.llvm.org/D92250
2020-11-28 00:02:06 +08:00
|
|
|
throw filesystem_error(_VSTD::forward<_Args>(__args)...);
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
}
|
|
|
|
#else
|
2019-02-05 23:46:52 +08:00
|
|
|
void __throw_filesystem_error(_Args&&...) {
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
_VSTD::abort();
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
// operational functions
|
|
|
|
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
path __absolute(const path&, error_code* __ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
path __canonical(const path&, error_code* __ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
void __copy(const path& __from, const path& __to, copy_options __opt,
|
|
|
|
error_code* __ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
bool __copy_file(const path& __from, const path& __to, copy_options __opt,
|
|
|
|
error_code* __ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
void __copy_symlink(const path& __existing_symlink, const path& __new_symlink,
|
|
|
|
error_code* __ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
bool __create_directories(const path& p, error_code* ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
bool __create_directory(const path& p, error_code* ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
bool __create_directory(const path& p, const path& attributes,
|
|
|
|
error_code* ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
void __create_directory_symlink(const path& __to, const path& __new_symlink,
|
|
|
|
error_code* __ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
void __create_hard_link(const path& __to, const path& __new_hard_link,
|
|
|
|
error_code* __ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
void __create_symlink(const path& __to, const path& __new_symlink,
|
|
|
|
error_code* __ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
path __current_path(error_code* __ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
void __current_path(const path&, error_code* __ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
bool __equivalent(const path&, const path&, error_code* __ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
uintmax_t __file_size(const path&, error_code* __ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
uintmax_t __hard_link_count(const path&, error_code* __ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
bool __fs_is_empty(const path& p, error_code* ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
file_time_type __last_write_time(const path& p, error_code* ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
void __last_write_time(const path& p, file_time_type new_time,
|
|
|
|
error_code* ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
void __permissions(const path&, perms, perm_options, error_code* = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
path __read_symlink(const path& p, error_code* ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
bool __remove(const path& p, error_code* ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
uintmax_t __remove_all(const path& p, error_code* ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
void __rename(const path& from, const path& to, error_code* ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
void __resize_file(const path& p, uintmax_t size, error_code* ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
space_info __space(const path&, error_code* __ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
file_status __status(const path&, error_code* __ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
file_status __symlink_status(const path&, error_code* __ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
path __system_complete(const path&, error_code* __ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
path __temp_directory_path(error_code* __ec = nullptr);
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
path __weakly_canonical(path const& __p, error_code* __ec = nullptr);
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY path current_path() {
|
|
|
|
return __current_path();
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY path current_path(error_code& __ec) {
|
|
|
|
return __current_path(&__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void current_path(const path& __p) {
|
|
|
|
__current_path(__p);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void current_path(const path& __p,
|
|
|
|
error_code& __ec) noexcept {
|
|
|
|
__current_path(__p, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY path absolute(const path& __p) {
|
|
|
|
return __absolute(__p);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY path absolute(const path& __p,
|
|
|
|
error_code& __ec) {
|
|
|
|
return __absolute(__p, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY path canonical(const path& __p) {
|
|
|
|
return __canonical(__p);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY path canonical(const path& __p,
|
|
|
|
error_code& __ec) {
|
|
|
|
return __canonical(__p, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void copy(const path& __from,
|
|
|
|
const path& __to) {
|
|
|
|
__copy(__from, __to, copy_options::none);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void copy(const path& __from, const path& __to,
|
|
|
|
error_code& __ec) {
|
|
|
|
__copy(__from, __to, copy_options::none, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void copy(const path& __from, const path& __to,
|
|
|
|
copy_options __opt) {
|
|
|
|
__copy(__from, __to, __opt);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void copy(const path& __from, const path& __to,
|
|
|
|
copy_options __opt,
|
|
|
|
error_code& __ec) {
|
|
|
|
__copy(__from, __to, __opt, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool copy_file(const path& __from,
|
|
|
|
const path& __to) {
|
|
|
|
return __copy_file(__from, __to, copy_options::none);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool
|
|
|
|
copy_file(const path& __from, const path& __to, error_code& __ec) {
|
|
|
|
return __copy_file(__from, __to, copy_options::none, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool
|
|
|
|
copy_file(const path& __from, const path& __to, copy_options __opt) {
|
|
|
|
return __copy_file(__from, __to, __opt);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool copy_file(const path& __from,
|
|
|
|
const path& __to,
|
|
|
|
copy_options __opt,
|
|
|
|
error_code& __ec) {
|
|
|
|
return __copy_file(__from, __to, __opt, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void copy_symlink(const path& __existing,
|
|
|
|
const path& __new) {
|
|
|
|
__copy_symlink(__existing, __new);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void
|
|
|
|
copy_symlink(const path& __ext, const path& __new, error_code& __ec) noexcept {
|
|
|
|
__copy_symlink(__ext, __new, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool create_directories(const path& __p) {
|
|
|
|
return __create_directories(__p);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool create_directories(const path& __p,
|
|
|
|
error_code& __ec) {
|
|
|
|
return __create_directories(__p, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool create_directory(const path& __p) {
|
|
|
|
return __create_directory(__p);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool
|
|
|
|
create_directory(const path& __p, error_code& __ec) noexcept {
|
|
|
|
return __create_directory(__p, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool create_directory(const path& __p,
|
|
|
|
const path& __attrs) {
|
|
|
|
return __create_directory(__p, __attrs);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool
|
|
|
|
create_directory(const path& __p, const path& __attrs,
|
|
|
|
error_code& __ec) noexcept {
|
|
|
|
return __create_directory(__p, __attrs, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void
|
|
|
|
create_directory_symlink(const path& __to, const path& __new) {
|
|
|
|
__create_directory_symlink(__to, __new);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void
|
|
|
|
create_directory_symlink(const path& __to, const path& __new,
|
|
|
|
error_code& __ec) noexcept {
|
|
|
|
__create_directory_symlink(__to, __new, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void create_hard_link(const path& __to,
|
|
|
|
const path& __new) {
|
|
|
|
__create_hard_link(__to, __new);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void
|
|
|
|
create_hard_link(const path& __to, const path& __new,
|
|
|
|
error_code& __ec) noexcept {
|
|
|
|
__create_hard_link(__to, __new, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void create_symlink(const path& __to,
|
|
|
|
const path& __new) {
|
|
|
|
__create_symlink(__to, __new);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void
|
|
|
|
create_symlink(const path& __to, const path& __new, error_code& __ec) noexcept {
|
|
|
|
return __create_symlink(__to, __new, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool status_known(file_status __s) noexcept {
|
|
|
|
return __s.type() != file_type::none;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool exists(file_status __s) noexcept {
|
|
|
|
return status_known(__s) && __s.type() != file_type::not_found;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool exists(const path& __p) {
|
|
|
|
return exists(__status(__p));
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool exists(const path& __p,
|
|
|
|
error_code& __ec) noexcept {
|
|
|
|
auto __s = __status(__p, &__ec);
|
|
|
|
if (status_known(__s))
|
|
|
|
__ec.clear();
|
|
|
|
return exists(__s);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool equivalent(const path& __p1,
|
|
|
|
const path& __p2) {
|
|
|
|
return __equivalent(__p1, __p2);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool
|
|
|
|
equivalent(const path& __p1, const path& __p2, error_code& __ec) noexcept {
|
|
|
|
return __equivalent(__p1, __p2, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY uintmax_t file_size(const path& __p) {
|
|
|
|
return __file_size(__p);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY uintmax_t
|
|
|
|
file_size(const path& __p, error_code& __ec) noexcept {
|
|
|
|
return __file_size(__p, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY uintmax_t hard_link_count(const path& __p) {
|
|
|
|
return __hard_link_count(__p);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY uintmax_t
|
|
|
|
hard_link_count(const path& __p, error_code& __ec) noexcept {
|
|
|
|
return __hard_link_count(__p, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_block_file(file_status __s) noexcept {
|
|
|
|
return __s.type() == file_type::block;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_block_file(const path& __p) {
|
|
|
|
return is_block_file(__status(__p));
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_block_file(const path& __p,
|
|
|
|
error_code& __ec) noexcept {
|
|
|
|
return is_block_file(__status(__p, &__ec));
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool
|
|
|
|
is_character_file(file_status __s) noexcept {
|
|
|
|
return __s.type() == file_type::character;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_character_file(const path& __p) {
|
|
|
|
return is_character_file(__status(__p));
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool
|
|
|
|
is_character_file(const path& __p, error_code& __ec) noexcept {
|
|
|
|
return is_character_file(__status(__p, &__ec));
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_directory(file_status __s) noexcept {
|
|
|
|
return __s.type() == file_type::directory;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_directory(const path& __p) {
|
|
|
|
return is_directory(__status(__p));
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_directory(const path& __p,
|
|
|
|
error_code& __ec) noexcept {
|
|
|
|
return is_directory(__status(__p, &__ec));
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_empty(const path& __p) {
|
|
|
|
return __fs_is_empty(__p);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_empty(const path& __p,
|
|
|
|
error_code& __ec) {
|
|
|
|
return __fs_is_empty(__p, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_fifo(file_status __s) noexcept {
|
|
|
|
return __s.type() == file_type::fifo;
|
|
|
|
}
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_fifo(const path& __p) {
|
|
|
|
return is_fifo(__status(__p));
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_fifo(const path& __p,
|
|
|
|
error_code& __ec) noexcept {
|
|
|
|
return is_fifo(__status(__p, &__ec));
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool
|
|
|
|
is_regular_file(file_status __s) noexcept {
|
|
|
|
return __s.type() == file_type::regular;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_regular_file(const path& __p) {
|
|
|
|
return is_regular_file(__status(__p));
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool
|
|
|
|
is_regular_file(const path& __p, error_code& __ec) noexcept {
|
|
|
|
return is_regular_file(__status(__p, &__ec));
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_socket(file_status __s) noexcept {
|
|
|
|
return __s.type() == file_type::socket;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_socket(const path& __p) {
|
|
|
|
return is_socket(__status(__p));
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_socket(const path& __p,
|
|
|
|
error_code& __ec) noexcept {
|
|
|
|
return is_socket(__status(__p, &__ec));
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_symlink(file_status __s) noexcept {
|
|
|
|
return __s.type() == file_type::symlink;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_symlink(const path& __p) {
|
|
|
|
return is_symlink(__symlink_status(__p));
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_symlink(const path& __p,
|
|
|
|
error_code& __ec) noexcept {
|
|
|
|
return is_symlink(__symlink_status(__p, &__ec));
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_other(file_status __s) noexcept {
|
|
|
|
return exists(__s) && !is_regular_file(__s) && !is_directory(__s) &&
|
|
|
|
!is_symlink(__s);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_other(const path& __p) {
|
|
|
|
return is_other(__status(__p));
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool is_other(const path& __p,
|
|
|
|
error_code& __ec) noexcept {
|
|
|
|
return is_other(__status(__p, &__ec));
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY file_time_type
|
|
|
|
last_write_time(const path& __p) {
|
|
|
|
return __last_write_time(__p);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY file_time_type
|
|
|
|
last_write_time(const path& __p, error_code& __ec) noexcept {
|
|
|
|
return __last_write_time(__p, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void last_write_time(const path& __p,
|
|
|
|
file_time_type __t) {
|
|
|
|
__last_write_time(__p, __t);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void
|
|
|
|
last_write_time(const path& __p, file_time_type __t,
|
|
|
|
error_code& __ec) noexcept {
|
|
|
|
__last_write_time(__p, __t, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void
|
|
|
|
permissions(const path& __p, perms __prms,
|
|
|
|
perm_options __opts = perm_options::replace) {
|
|
|
|
__permissions(__p, __prms, __opts);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void permissions(const path& __p, perms __prms,
|
|
|
|
error_code& __ec) noexcept {
|
|
|
|
__permissions(__p, __prms, perm_options::replace, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void permissions(const path& __p, perms __prms,
|
|
|
|
perm_options __opts,
|
|
|
|
error_code& __ec) {
|
|
|
|
__permissions(__p, __prms, __opts, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY path proximate(const path& __p,
|
|
|
|
const path& __base,
|
|
|
|
error_code& __ec) {
|
|
|
|
path __tmp = __weakly_canonical(__p, &__ec);
|
|
|
|
if (__ec)
|
|
|
|
return {};
|
|
|
|
path __tmp_base = __weakly_canonical(__base, &__ec);
|
|
|
|
if (__ec)
|
|
|
|
return {};
|
|
|
|
return __tmp.lexically_proximate(__tmp_base);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY path proximate(const path& __p,
|
|
|
|
error_code& __ec) {
|
|
|
|
return proximate(__p, current_path(), __ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY path
|
|
|
|
proximate(const path& __p, const path& __base = current_path()) {
|
|
|
|
return __weakly_canonical(__p).lexically_proximate(
|
|
|
|
__weakly_canonical(__base));
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY path read_symlink(const path& __p) {
|
|
|
|
return __read_symlink(__p);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY path read_symlink(const path& __p,
|
|
|
|
error_code& __ec) {
|
|
|
|
return __read_symlink(__p, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY path relative(const path& __p,
|
|
|
|
const path& __base,
|
|
|
|
error_code& __ec) {
|
|
|
|
path __tmp = __weakly_canonical(__p, &__ec);
|
|
|
|
if (__ec)
|
|
|
|
return path();
|
|
|
|
path __tmpbase = __weakly_canonical(__base, &__ec);
|
|
|
|
if (__ec)
|
|
|
|
return path();
|
|
|
|
return __tmp.lexically_relative(__tmpbase);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY path relative(const path& __p,
|
|
|
|
error_code& __ec) {
|
|
|
|
return relative(__p, current_path(), __ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY path
|
|
|
|
relative(const path& __p, const path& __base = current_path()) {
|
|
|
|
return __weakly_canonical(__p).lexically_relative(__weakly_canonical(__base));
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool remove(const path& __p) {
|
|
|
|
return __remove(__p);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool remove(const path& __p,
|
|
|
|
error_code& __ec) noexcept {
|
|
|
|
return __remove(__p, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY uintmax_t remove_all(const path& __p) {
|
|
|
|
return __remove_all(__p);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY uintmax_t remove_all(const path& __p,
|
|
|
|
error_code& __ec) {
|
|
|
|
return __remove_all(__p, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void rename(const path& __from,
|
|
|
|
const path& __to) {
|
|
|
|
return __rename(__from, __to);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void
|
|
|
|
rename(const path& __from, const path& __to, error_code& __ec) noexcept {
|
|
|
|
return __rename(__from, __to, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void resize_file(const path& __p,
|
|
|
|
uintmax_t __ns) {
|
|
|
|
return __resize_file(__p, __ns);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY void
|
|
|
|
resize_file(const path& __p, uintmax_t __ns, error_code& __ec) noexcept {
|
|
|
|
return __resize_file(__p, __ns, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY space_info space(const path& __p) {
|
|
|
|
return __space(__p);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY space_info space(const path& __p,
|
|
|
|
error_code& __ec) noexcept {
|
|
|
|
return __space(__p, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY file_status status(const path& __p) {
|
|
|
|
return __status(__p);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY file_status status(const path& __p,
|
|
|
|
error_code& __ec) noexcept {
|
|
|
|
return __status(__p, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY file_status symlink_status(const path& __p) {
|
|
|
|
return __symlink_status(__p);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY file_status
|
|
|
|
symlink_status(const path& __p, error_code& __ec) noexcept {
|
|
|
|
return __symlink_status(__p, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY path temp_directory_path() {
|
|
|
|
return __temp_directory_path();
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY path temp_directory_path(error_code& __ec) {
|
|
|
|
return __temp_directory_path(&__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY path weakly_canonical(path const& __p) {
|
|
|
|
return __weakly_canonical(__p);
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY path weakly_canonical(path const& __p,
|
|
|
|
error_code& __ec) {
|
|
|
|
return __weakly_canonical(__p, &__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
class directory_iterator;
|
|
|
|
class recursive_directory_iterator;
|
2019-03-20 01:47:53 +08:00
|
|
|
class _LIBCPP_HIDDEN __dir_stream;
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
|
|
|
|
class directory_entry {
|
|
|
|
typedef _VSTD_FS::path _Path;
|
|
|
|
|
|
|
|
public:
|
|
|
|
// constructors and destructors
|
|
|
|
directory_entry() noexcept = default;
|
|
|
|
directory_entry(directory_entry const&) = default;
|
|
|
|
directory_entry(directory_entry&&) noexcept = default;
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
explicit directory_entry(_Path const& __p) : __p_(__p) {
|
|
|
|
error_code __ec;
|
|
|
|
__refresh(&__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
directory_entry(_Path const& __p, error_code& __ec) : __p_(__p) {
|
|
|
|
__refresh(&__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
~directory_entry() {}
|
|
|
|
|
|
|
|
directory_entry& operator=(directory_entry const&) = default;
|
|
|
|
directory_entry& operator=(directory_entry&&) noexcept = default;
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
void assign(_Path const& __p) {
|
|
|
|
__p_ = __p;
|
|
|
|
error_code __ec;
|
|
|
|
__refresh(&__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
void assign(_Path const& __p, error_code& __ec) {
|
|
|
|
__p_ = __p;
|
|
|
|
__refresh(&__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
void replace_filename(_Path const& __p) {
|
|
|
|
__p_.replace_filename(__p);
|
|
|
|
error_code __ec;
|
|
|
|
__refresh(&__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
void replace_filename(_Path const& __p, error_code& __ec) {
|
|
|
|
__p_ = __p_.parent_path() / __p;
|
|
|
|
__refresh(&__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
void refresh() { __refresh(); }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
void refresh(error_code& __ec) noexcept { __refresh(&__ec); }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
_Path const& path() const noexcept { return __p_; }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
operator const _Path&() const noexcept { return __p_; }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool exists() const { return _VSTD_FS::exists(file_status{__get_ft()}); }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool exists(error_code& __ec) const noexcept {
|
|
|
|
return _VSTD_FS::exists(file_status{__get_ft(&__ec)});
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool is_block_file() const { return __get_ft() == file_type::block; }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool is_block_file(error_code& __ec) const noexcept {
|
|
|
|
return __get_ft(&__ec) == file_type::block;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool is_character_file() const { return __get_ft() == file_type::character; }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool is_character_file(error_code& __ec) const noexcept {
|
|
|
|
return __get_ft(&__ec) == file_type::character;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool is_directory() const { return __get_ft() == file_type::directory; }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool is_directory(error_code& __ec) const noexcept {
|
|
|
|
return __get_ft(&__ec) == file_type::directory;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool is_fifo() const { return __get_ft() == file_type::fifo; }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool is_fifo(error_code& __ec) const noexcept {
|
|
|
|
return __get_ft(&__ec) == file_type::fifo;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool is_other() const { return _VSTD_FS::is_other(file_status{__get_ft()}); }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool is_other(error_code& __ec) const noexcept {
|
|
|
|
return _VSTD_FS::is_other(file_status{__get_ft(&__ec)});
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool is_regular_file() const { return __get_ft() == file_type::regular; }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool is_regular_file(error_code& __ec) const noexcept {
|
|
|
|
return __get_ft(&__ec) == file_type::regular;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool is_socket() const { return __get_ft() == file_type::socket; }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool is_socket(error_code& __ec) const noexcept {
|
|
|
|
return __get_ft(&__ec) == file_type::socket;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool is_symlink() const { return __get_sym_ft() == file_type::symlink; }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool is_symlink(error_code& __ec) const noexcept {
|
|
|
|
return __get_sym_ft(&__ec) == file_type::symlink;
|
|
|
|
}
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
uintmax_t file_size() const { return __get_size(); }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
uintmax_t file_size(error_code& __ec) const noexcept {
|
|
|
|
return __get_size(&__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
uintmax_t hard_link_count() const { return __get_nlink(); }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
uintmax_t hard_link_count(error_code& __ec) const noexcept {
|
|
|
|
return __get_nlink(&__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
file_time_type last_write_time() const { return __get_write_time(); }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
file_time_type last_write_time(error_code& __ec) const noexcept {
|
|
|
|
return __get_write_time(&__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
file_status status() const { return __get_status(); }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
file_status status(error_code& __ec) const noexcept {
|
|
|
|
return __get_status(&__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
file_status symlink_status() const { return __get_symlink_status(); }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
file_status symlink_status(error_code& __ec) const noexcept {
|
|
|
|
return __get_symlink_status(&__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool operator<(directory_entry const& __rhs) const noexcept {
|
|
|
|
return __p_ < __rhs.__p_;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool operator==(directory_entry const& __rhs) const noexcept {
|
|
|
|
return __p_ == __rhs.__p_;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool operator!=(directory_entry const& __rhs) const noexcept {
|
|
|
|
return __p_ != __rhs.__p_;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool operator<=(directory_entry const& __rhs) const noexcept {
|
|
|
|
return __p_ <= __rhs.__p_;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool operator>(directory_entry const& __rhs) const noexcept {
|
|
|
|
return __p_ > __rhs.__p_;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool operator>=(directory_entry const& __rhs) const noexcept {
|
|
|
|
return __p_ >= __rhs.__p_;
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
friend class directory_iterator;
|
|
|
|
friend class recursive_directory_iterator;
|
|
|
|
friend class __dir_stream;
|
|
|
|
|
|
|
|
enum _CacheType : unsigned char {
|
|
|
|
_Empty,
|
|
|
|
_IterSymlink,
|
|
|
|
_IterNonSymlink,
|
|
|
|
_RefreshSymlink,
|
|
|
|
_RefreshSymlinkUnresolved,
|
|
|
|
_RefreshNonSymlink
|
|
|
|
};
|
|
|
|
|
|
|
|
struct __cached_data {
|
|
|
|
uintmax_t __size_;
|
|
|
|
uintmax_t __nlink_;
|
|
|
|
file_time_type __write_time_;
|
|
|
|
perms __sym_perms_;
|
|
|
|
perms __non_sym_perms_;
|
|
|
|
file_type __type_;
|
|
|
|
_CacheType __cache_type_;
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
__cached_data() noexcept { __reset(); }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
void __reset() {
|
|
|
|
__cache_type_ = _Empty;
|
|
|
|
__type_ = file_type::none;
|
|
|
|
__sym_perms_ = __non_sym_perms_ = perms::unknown;
|
|
|
|
__size_ = __nlink_ = uintmax_t(-1);
|
|
|
|
__write_time_ = file_time_type::min();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
static __cached_data __create_iter_result(file_type __ft) {
|
|
|
|
__cached_data __data;
|
|
|
|
__data.__type_ = __ft;
|
|
|
|
__data.__cache_type_ = [&]() {
|
|
|
|
switch (__ft) {
|
|
|
|
case file_type::none:
|
|
|
|
return _Empty;
|
|
|
|
case file_type::symlink:
|
|
|
|
return _IterSymlink;
|
|
|
|
default:
|
|
|
|
return _IterNonSymlink;
|
|
|
|
}
|
|
|
|
}();
|
|
|
|
return __data;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
void __assign_iter_entry(_Path&& __p, __cached_data __dt) {
|
[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.
I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:
- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.
- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.
- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.
In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.
Differential Revision: https://reviews.llvm.org/D92250
2020-11-28 00:02:06 +08:00
|
|
|
__p_ = _VSTD::move(__p);
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
__data_ = __dt;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
error_code __do_refresh() noexcept;
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
static bool __is_dne_error(error_code const& __ec) {
|
|
|
|
if (!__ec)
|
|
|
|
return true;
|
|
|
|
switch (static_cast<errc>(__ec.value())) {
|
|
|
|
case errc::no_such_file_or_directory:
|
|
|
|
case errc::not_a_directory:
|
|
|
|
return true;
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
void __handle_error(const char* __msg, error_code* __dest_ec,
|
|
|
|
error_code const& __ec, bool __allow_dne = false) const {
|
|
|
|
if (__dest_ec) {
|
|
|
|
*__dest_ec = __ec;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (__ec && (!__allow_dne || !__is_dne_error(__ec)))
|
|
|
|
__throw_filesystem_error(__msg, __p_, __ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
void __refresh(error_code* __ec = nullptr) {
|
|
|
|
__handle_error("in directory_entry::refresh", __ec, __do_refresh(),
|
|
|
|
/*allow_dne*/ true);
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
file_type __get_sym_ft(error_code* __ec = nullptr) const {
|
|
|
|
switch (__data_.__cache_type_) {
|
|
|
|
case _Empty:
|
|
|
|
return __symlink_status(__p_, __ec).type();
|
|
|
|
case _IterSymlink:
|
|
|
|
case _RefreshSymlink:
|
|
|
|
case _RefreshSymlinkUnresolved:
|
|
|
|
if (__ec)
|
|
|
|
__ec->clear();
|
|
|
|
return file_type::symlink;
|
|
|
|
case _IterNonSymlink:
|
|
|
|
case _RefreshNonSymlink:
|
|
|
|
file_status __st(__data_.__type_);
|
|
|
|
if (__ec && !_VSTD_FS::exists(__st))
|
|
|
|
*__ec = make_error_code(errc::no_such_file_or_directory);
|
|
|
|
else if (__ec)
|
|
|
|
__ec->clear();
|
|
|
|
return __data_.__type_;
|
|
|
|
}
|
|
|
|
_LIBCPP_UNREACHABLE();
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
file_type __get_ft(error_code* __ec = nullptr) const {
|
|
|
|
switch (__data_.__cache_type_) {
|
|
|
|
case _Empty:
|
|
|
|
case _IterSymlink:
|
|
|
|
case _RefreshSymlinkUnresolved:
|
|
|
|
return __status(__p_, __ec).type();
|
|
|
|
case _IterNonSymlink:
|
|
|
|
case _RefreshNonSymlink:
|
|
|
|
case _RefreshSymlink: {
|
|
|
|
file_status __st(__data_.__type_);
|
|
|
|
if (__ec && !_VSTD_FS::exists(__st))
|
|
|
|
*__ec = make_error_code(errc::no_such_file_or_directory);
|
|
|
|
else if (__ec)
|
|
|
|
__ec->clear();
|
|
|
|
return __data_.__type_;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
_LIBCPP_UNREACHABLE();
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
file_status __get_status(error_code* __ec = nullptr) const {
|
|
|
|
switch (__data_.__cache_type_) {
|
|
|
|
case _Empty:
|
|
|
|
case _IterNonSymlink:
|
|
|
|
case _IterSymlink:
|
|
|
|
case _RefreshSymlinkUnresolved:
|
|
|
|
return __status(__p_, __ec);
|
|
|
|
case _RefreshNonSymlink:
|
|
|
|
case _RefreshSymlink:
|
|
|
|
return file_status(__get_ft(__ec), __data_.__non_sym_perms_);
|
|
|
|
}
|
|
|
|
_LIBCPP_UNREACHABLE();
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
file_status __get_symlink_status(error_code* __ec = nullptr) const {
|
|
|
|
switch (__data_.__cache_type_) {
|
|
|
|
case _Empty:
|
|
|
|
case _IterNonSymlink:
|
|
|
|
case _IterSymlink:
|
|
|
|
return __symlink_status(__p_, __ec);
|
|
|
|
case _RefreshNonSymlink:
|
|
|
|
return file_status(__get_sym_ft(__ec), __data_.__non_sym_perms_);
|
|
|
|
case _RefreshSymlink:
|
|
|
|
case _RefreshSymlinkUnresolved:
|
|
|
|
return file_status(__get_sym_ft(__ec), __data_.__sym_perms_);
|
|
|
|
}
|
|
|
|
_LIBCPP_UNREACHABLE();
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
uintmax_t __get_size(error_code* __ec = nullptr) const {
|
|
|
|
switch (__data_.__cache_type_) {
|
|
|
|
case _Empty:
|
|
|
|
case _IterNonSymlink:
|
|
|
|
case _IterSymlink:
|
|
|
|
case _RefreshSymlinkUnresolved:
|
|
|
|
return _VSTD_FS::__file_size(__p_, __ec);
|
|
|
|
case _RefreshSymlink:
|
|
|
|
case _RefreshNonSymlink: {
|
|
|
|
error_code __m_ec;
|
|
|
|
file_status __st(__get_ft(&__m_ec));
|
|
|
|
__handle_error("in directory_entry::file_size", __ec, __m_ec);
|
|
|
|
if (_VSTD_FS::exists(__st) && !_VSTD_FS::is_regular_file(__st)) {
|
|
|
|
errc __err_kind = _VSTD_FS::is_directory(__st) ? errc::is_a_directory
|
|
|
|
: errc::not_supported;
|
|
|
|
__handle_error("in directory_entry::file_size", __ec,
|
|
|
|
make_error_code(__err_kind));
|
|
|
|
}
|
|
|
|
return __data_.__size_;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
_LIBCPP_UNREACHABLE();
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
uintmax_t __get_nlink(error_code* __ec = nullptr) const {
|
|
|
|
switch (__data_.__cache_type_) {
|
|
|
|
case _Empty:
|
|
|
|
case _IterNonSymlink:
|
|
|
|
case _IterSymlink:
|
|
|
|
case _RefreshSymlinkUnresolved:
|
|
|
|
return _VSTD_FS::__hard_link_count(__p_, __ec);
|
|
|
|
case _RefreshSymlink:
|
|
|
|
case _RefreshNonSymlink: {
|
|
|
|
error_code __m_ec;
|
|
|
|
(void)__get_ft(&__m_ec);
|
|
|
|
__handle_error("in directory_entry::hard_link_count", __ec, __m_ec);
|
|
|
|
return __data_.__nlink_;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
_LIBCPP_UNREACHABLE();
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
file_time_type __get_write_time(error_code* __ec = nullptr) const {
|
|
|
|
switch (__data_.__cache_type_) {
|
|
|
|
case _Empty:
|
|
|
|
case _IterNonSymlink:
|
|
|
|
case _IterSymlink:
|
|
|
|
case _RefreshSymlinkUnresolved:
|
|
|
|
return _VSTD_FS::__last_write_time(__p_, __ec);
|
|
|
|
case _RefreshSymlink:
|
|
|
|
case _RefreshNonSymlink: {
|
|
|
|
error_code __m_ec;
|
|
|
|
file_status __st(__get_ft(&__m_ec));
|
|
|
|
__handle_error("in directory_entry::last_write_time", __ec, __m_ec);
|
|
|
|
if (_VSTD_FS::exists(__st) &&
|
|
|
|
__data_.__write_time_ == file_time_type::min())
|
|
|
|
__handle_error("in directory_entry::last_write_time", __ec,
|
|
|
|
make_error_code(errc::value_too_large));
|
|
|
|
return __data_.__write_time_;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
_LIBCPP_UNREACHABLE();
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
_Path __p_;
|
|
|
|
__cached_data __data_;
|
|
|
|
};
|
|
|
|
|
|
|
|
class __dir_element_proxy {
|
|
|
|
public:
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY directory_entry operator*() {
|
|
|
|
return _VSTD::move(__elem_);
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
friend class directory_iterator;
|
|
|
|
friend class recursive_directory_iterator;
|
|
|
|
explicit __dir_element_proxy(directory_entry const& __e) : __elem_(__e) {}
|
|
|
|
__dir_element_proxy(__dir_element_proxy&& __o)
|
|
|
|
: __elem_(_VSTD::move(__o.__elem_)) {}
|
|
|
|
directory_entry __elem_;
|
|
|
|
};
|
|
|
|
|
|
|
|
class directory_iterator {
|
|
|
|
public:
|
|
|
|
typedef directory_entry value_type;
|
|
|
|
typedef ptrdiff_t difference_type;
|
|
|
|
typedef value_type const* pointer;
|
|
|
|
typedef value_type const& reference;
|
|
|
|
typedef input_iterator_tag iterator_category;
|
|
|
|
|
|
|
|
public:
|
|
|
|
//ctor & dtor
|
|
|
|
directory_iterator() noexcept {}
|
|
|
|
|
|
|
|
explicit directory_iterator(const path& __p)
|
|
|
|
: directory_iterator(__p, nullptr) {}
|
|
|
|
|
|
|
|
directory_iterator(const path& __p, directory_options __opts)
|
|
|
|
: directory_iterator(__p, nullptr, __opts) {}
|
|
|
|
|
|
|
|
directory_iterator(const path& __p, error_code& __ec)
|
|
|
|
: directory_iterator(__p, &__ec) {}
|
|
|
|
|
|
|
|
directory_iterator(const path& __p, directory_options __opts,
|
|
|
|
error_code& __ec)
|
|
|
|
: directory_iterator(__p, &__ec, __opts) {}
|
|
|
|
|
|
|
|
directory_iterator(const directory_iterator&) = default;
|
|
|
|
directory_iterator(directory_iterator&&) = default;
|
|
|
|
directory_iterator& operator=(const directory_iterator&) = default;
|
|
|
|
|
|
|
|
directory_iterator& operator=(directory_iterator&& __o) noexcept {
|
|
|
|
// non-default implementation provided to support self-move assign.
|
|
|
|
if (this != &__o) {
|
|
|
|
__imp_ = _VSTD::move(__o.__imp_);
|
|
|
|
}
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
~directory_iterator() = default;
|
|
|
|
|
|
|
|
const directory_entry& operator*() const {
|
|
|
|
_LIBCPP_ASSERT(__imp_, "The end iterator cannot be dereferenced");
|
|
|
|
return __dereference();
|
|
|
|
}
|
|
|
|
|
|
|
|
const directory_entry* operator->() const { return &**this; }
|
|
|
|
|
|
|
|
directory_iterator& operator++() { return __increment(); }
|
|
|
|
|
|
|
|
__dir_element_proxy operator++(int) {
|
|
|
|
__dir_element_proxy __p(**this);
|
|
|
|
__increment();
|
|
|
|
return __p;
|
|
|
|
}
|
|
|
|
|
|
|
|
directory_iterator& increment(error_code& __ec) { return __increment(&__ec); }
|
|
|
|
|
|
|
|
private:
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY friend bool
|
|
|
|
operator==(const directory_iterator& __lhs,
|
|
|
|
const directory_iterator& __rhs) noexcept;
|
|
|
|
|
|
|
|
// construct the dir_stream
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
directory_iterator(const path&, error_code*,
|
|
|
|
directory_options = directory_options::none);
|
|
|
|
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
directory_iterator& __increment(error_code* __ec = nullptr);
|
|
|
|
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
const directory_entry& __dereference() const;
|
|
|
|
|
|
|
|
private:
|
|
|
|
shared_ptr<__dir_stream> __imp_;
|
|
|
|
};
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool
|
|
|
|
operator==(const directory_iterator& __lhs,
|
|
|
|
const directory_iterator& __rhs) noexcept {
|
|
|
|
return __lhs.__imp_ == __rhs.__imp_;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool
|
|
|
|
operator!=(const directory_iterator& __lhs,
|
|
|
|
const directory_iterator& __rhs) noexcept {
|
|
|
|
return !(__lhs == __rhs);
|
|
|
|
}
|
|
|
|
|
|
|
|
// enable directory_iterator range-based for statements
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY directory_iterator
|
|
|
|
begin(directory_iterator __iter) noexcept {
|
|
|
|
return __iter;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY directory_iterator
|
|
|
|
end(const directory_iterator&) noexcept {
|
|
|
|
return directory_iterator();
|
|
|
|
}
|
|
|
|
|
|
|
|
class recursive_directory_iterator {
|
|
|
|
public:
|
|
|
|
using value_type = directory_entry;
|
[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.
I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:
- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.
- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.
- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.
In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.
Differential Revision: https://reviews.llvm.org/D92250
2020-11-28 00:02:06 +08:00
|
|
|
using difference_type = ptrdiff_t;
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
using pointer = directory_entry const*;
|
|
|
|
using reference = directory_entry const&;
|
[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.
I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:
- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.
- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.
- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.
In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.
Differential Revision: https://reviews.llvm.org/D92250
2020-11-28 00:02:06 +08:00
|
|
|
using iterator_category = input_iterator_tag;
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
|
|
|
|
public:
|
|
|
|
// constructors and destructor
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
recursive_directory_iterator() noexcept : __rec_(false) {}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
explicit recursive_directory_iterator(
|
|
|
|
const path& __p, directory_options __xoptions = directory_options::none)
|
|
|
|
: recursive_directory_iterator(__p, __xoptions, nullptr) {}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
recursive_directory_iterator(const path& __p, directory_options __xoptions,
|
|
|
|
error_code& __ec)
|
|
|
|
: recursive_directory_iterator(__p, __xoptions, &__ec) {}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
recursive_directory_iterator(const path& __p, error_code& __ec)
|
|
|
|
: recursive_directory_iterator(__p, directory_options::none, &__ec) {}
|
|
|
|
|
|
|
|
recursive_directory_iterator(const recursive_directory_iterator&) = default;
|
|
|
|
recursive_directory_iterator(recursive_directory_iterator&&) = default;
|
|
|
|
|
|
|
|
recursive_directory_iterator&
|
|
|
|
operator=(const recursive_directory_iterator&) = default;
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
recursive_directory_iterator&
|
|
|
|
operator=(recursive_directory_iterator&& __o) noexcept {
|
|
|
|
// non-default implementation provided to support self-move assign.
|
|
|
|
if (this != &__o) {
|
|
|
|
__imp_ = _VSTD::move(__o.__imp_);
|
|
|
|
__rec_ = __o.__rec_;
|
|
|
|
}
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
~recursive_directory_iterator() = default;
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
const directory_entry& operator*() const { return __dereference(); }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
const directory_entry* operator->() const { return &__dereference(); }
|
|
|
|
|
|
|
|
recursive_directory_iterator& operator++() { return __increment(); }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
__dir_element_proxy operator++(int) {
|
|
|
|
__dir_element_proxy __p(**this);
|
|
|
|
__increment();
|
|
|
|
return __p;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
recursive_directory_iterator& increment(error_code& __ec) {
|
|
|
|
return __increment(&__ec);
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_FUNC_VIS directory_options options() const;
|
|
|
|
_LIBCPP_FUNC_VIS int depth() const;
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
void pop() { __pop(); }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
void pop(error_code& __ec) { __pop(&__ec); }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
bool recursion_pending() const { return __rec_; }
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
void disable_recursion_pending() { __rec_ = false; }
|
|
|
|
|
|
|
|
private:
|
2019-08-13 23:02:53 +08:00
|
|
|
_LIBCPP_FUNC_VIS
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
recursive_directory_iterator(const path& __p, directory_options __opt,
|
|
|
|
error_code* __ec);
|
|
|
|
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
const directory_entry& __dereference() const;
|
|
|
|
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
bool __try_recursion(error_code* __ec);
|
|
|
|
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
void __advance(error_code* __ec = nullptr);
|
|
|
|
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
recursive_directory_iterator& __increment(error_code* __ec = nullptr);
|
|
|
|
|
|
|
|
_LIBCPP_FUNC_VIS
|
|
|
|
void __pop(error_code* __ec = nullptr);
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY friend bool
|
|
|
|
operator==(const recursive_directory_iterator&,
|
|
|
|
const recursive_directory_iterator&) noexcept;
|
|
|
|
|
2019-03-20 01:47:53 +08:00
|
|
|
struct _LIBCPP_HIDDEN __shared_imp;
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
shared_ptr<__shared_imp> __imp_;
|
|
|
|
bool __rec_;
|
|
|
|
}; // class recursive_directory_iterator
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY bool
|
|
|
|
operator==(const recursive_directory_iterator& __lhs,
|
|
|
|
const recursive_directory_iterator& __rhs) noexcept {
|
|
|
|
return __lhs.__imp_ == __rhs.__imp_;
|
|
|
|
}
|
|
|
|
|
|
|
|
_LIBCPP_INLINE_VISIBILITY
|
|
|
|
inline bool operator!=(const recursive_directory_iterator& __lhs,
|
|
|
|
const recursive_directory_iterator& __rhs) noexcept {
|
|
|
|
return !(__lhs == __rhs);
|
|
|
|
}
|
|
|
|
// enable recursive_directory_iterator range-based for statements
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY recursive_directory_iterator
|
|
|
|
begin(recursive_directory_iterator __iter) noexcept {
|
|
|
|
return __iter;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline _LIBCPP_INLINE_VISIBILITY recursive_directory_iterator
|
|
|
|
end(const recursive_directory_iterator&) noexcept {
|
|
|
|
return recursive_directory_iterator();
|
|
|
|
}
|
|
|
|
|
2019-03-21 05:18:14 +08:00
|
|
|
_LIBCPP_AVAILABILITY_FILESYSTEM_POP
|
|
|
|
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
_LIBCPP_END_NAMESPACE_FILESYSTEM
|
|
|
|
|
|
|
|
#endif // !_LIBCPP_CXX03_LANG
|
|
|
|
|
|
|
|
_LIBCPP_POP_MACROS
|
|
|
|
|
|
|
|
#endif // _LIBCPP_FILESYSTEM
|