maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/libcxx/include/filesystem

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

3042 lines
93 KiB
Plaintext
Raw Normal View History

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 -------------------------------===//
//
Update more file headers across all of the LLVM projects in the monorepo to reflect the new license. These used slightly different spellings that defeated my regular expressions. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351648
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
[libc++] LWG3480: make (recursive_)directory_iterator C++20 ranges Implement LWG3480 which enables `directory_iterator` and `recursive_directory_iterator` to be both a `borrowed_range` and a `view`. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D111644
2021-10-14 23:53:43 +08:00
namespace std::filesystem {
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 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;
[libc++] LWG3480: make (recursive_)directory_iterator C++20 ranges Implement LWG3480 which enables `directory_iterator` and `recursive_directory_iterator` to be both a `borrowed_range` and a `view`. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D111644
2021-10-14 23:53:43 +08:00
directory_iterator end(directory_iterator) 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
class recursive_directory_iterator;
// enable recursive_directory_iterator range-based for statements
recursive_directory_iterator begin(recursive_directory_iterator iter) noexcept;
[libc++] LWG3480: make (recursive_)directory_iterator C++20 ranges Implement LWG3480 which enables `directory_iterator` and `recursive_directory_iterator` to be both a `borrowed_range` and a `view`. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D111644
2021-10-14 23:53:43 +08:00
recursive_directory_iterator end(recursive_directory_iterator) 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
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);
[libc++] LWG3480: make (recursive_)directory_iterator C++20 ranges Implement LWG3480 which enables `directory_iterator` and `recursive_directory_iterator` to be both a `borrowed_range` and a `view`. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D111644
2021-10-14 23:53:43 +08:00
} // namespace std::filesystem
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
[libc++] LWG3480: make (recursive_)directory_iterator C++20 ranges Implement LWG3480 which enables `directory_iterator` and `recursive_directory_iterator` to be both a `borrowed_range` and a `view`. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D111644
2021-10-14 23:53:43 +08:00
template <>
inline constexpr bool std::ranges::enable_borrowed_range<std::filesystem::directory_iterator> = true;
template <>
inline constexpr bool std::ranges::enable_borrowed_range<std::filesystem::recursive_directory_iterator> = true;
template <>
inline constexpr bool std::ranges::enable_view<std::filesystem::directory_iterator> = true;
template <>
inline constexpr bool std::ranges::enable_view<std::filesystem::recursive_directory_iterator> = true;
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
*/
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
#include <__availability>
[libc++] Alphabetize and include-what-you-use. NFCI. Differential Revision: https://reviews.llvm.org/D102781
2021-05-19 23:57:04 +08:00
#include <__config>
#include <__debug>
[libc++] LWG3480: make (recursive_)directory_iterator C++20 ranges Implement LWG3480 which enables `directory_iterator` and `recursive_directory_iterator` to be both a `borrowed_range` and a `view`. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D111644
2021-10-14 23:53:43 +08:00
#include <__ranges/enable_borrowed_range.h>
#include <__ranges/enable_view.h>
[libcxx][modularisation] moves <utility> content out of <type_traits> Moves: * `std::move`, `std::forward`, `std::declval`, and `std::swap` into `__utility/${FUNCTION_NAME}`. * `std::swap_ranges` and `std::iter_swap` into `__algorithm/${FUNCTION_NAME}` Differential Revision: https://reviews.llvm.org/D103734
2021-06-05 10:47:47 +08:00
#include <__utility/forward.h>
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 <chrono>
[libc++] Header inclusion tests. As mandated by the Standard's various synopses, e.g. [iterator.synopsis]. Searching the TeX source for '#include' is a good way to find all of these mandates. The new tests are all autogenerated by utils/generate_header_inclusion_tests.py. I was SHOCKED by how many mandates there are, and how many of them libc++ wasn't conforming with. Differential Revision: https://reviews.llvm.org/D99309
2021-03-25 06:19:12 +08:00
#include <compare>
[libc++] Alphabetize and include-what-you-use. NFCI. Differential Revision: https://reviews.llvm.org/D102781
2021-05-19 23:57:04 +08:00
#include <cstddef>
#include <cstdlib>
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 <iosfwd>
[libc++] Alphabetize and include-what-you-use. NFCI. Differential Revision: https://reviews.llvm.org/D102781
2021-05-19 23:57:04 +08:00
#include <iterator>
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 <memory>
#include <stack>
#include <string>
[libc++] Alphabetize and include-what-you-use. NFCI. Differential Revision: https://reviews.llvm.org/D102781
2021-05-19 23:57:04 +08:00
#include <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
#include <system_error>
#include <utility>
Implement the infrastructure for feature-test macros. Very few actual feature test macros, though. Reviewed as: https://reviews.llvm.org/D51955 llvm-svn: 342073
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
[libc++] Add a libc++ configuration that does not support localization When porting libc++ to embedded systems, it can be useful to drop support for localization, which these systems don't implement or care about. Differential Revision: https://reviews.llvm.org/D90072
2020-10-10 03:31:05 +08:00
#if !defined(_LIBCPP_HAS_NO_LOCALIZATION)
# include <locale>
# include <iomanip> // for quoted
#endif
[libc++] Make LIBCXX_ENABLE_FILESYSTEM fully consistent Previously, LIBCXX_ENABLE_FILESYSTEM controlled only whether the filesystem support was compiled into libc++'s library. This commit promotes the setting to a first-class option like LIBCXX_ENABLE_LOCALIZATION, where the whole library is aware of the setting and features that depend on <filesystem> won't be provided at all. The test suite is also properly annotated such that tests that depend on <filesystem> are disabled when the library doesn't support it. This is an alternative to https://llvm.org/D94824, but also an improvement along the lines of LIBCXX_ENABLE_LOCALIZATION that I had been wanting to make for a while. Differential Revision: https://reviews.llvm.org/D94921
2021-01-19 01:18:18 +08:00
#if defined(_LIBCPP_HAS_NO_FILESYSTEM_LIBRARY)
[libc++][nfc] Improve error diagnostics. The error message for disabled filesystem and locale support is now done in the same fashion as ranges and format in D106763. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D106935
2021-07-28 14:11:52 +08:00
# error "The Filesystem library is not supported since libc++ has been configured with LIBCXX_ENABLE_FILESYSTEM disabled"
[libc++] Make LIBCXX_ENABLE_FILESYSTEM fully consistent Previously, LIBCXX_ENABLE_FILESYSTEM controlled only whether the filesystem support was compiled into libc++'s library. This commit promotes the setting to a first-class option like LIBCXX_ENABLE_LOCALIZATION, where the whole library is aware of the setting and features that depend on <filesystem> won't be provided at all. The test suite is also properly annotated such that tests that depend on <filesystem> are disabled when the library doesn't support it. This is an alternative to https://llvm.org/D94824, but also an improvement along the lines of LIBCXX_ENABLE_LOCALIZATION that I had been wanting to make for a while. Differential Revision: https://reviews.llvm.org/D94921
2021-01-19 01:18:18 +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
#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
[libc++] Mark <filesystem> as unavailable on Apple platforms using pragmas Summary: Also add the corresponding XFAILs to tests that require filesystem. The approach taken to mark <filesystem> as unavailable in this patch is to mark all the header as unavailable using #pragma clang attribute. Marking each declaration using the attribute is more intrusive and does not provide a lot of value right now because pretty much everything in <filesystem> requires dylib support, often transitively. This is an alternative to https://reviews.llvm.org/D59093. A similar (but partial) patch was already applied in r356558. Reviewers: mclow.lists, EricWF, serge-sans-paille Subscribers: christof, jkorous, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D59224 llvm-svn: 356616
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;
};
[libc++][NFC] Replace tab with whitespace in comment There is a stray tab character in a comment block. Replace the tab character with a space for consistency with other comments.
2021-10-11 00:53:35 +08:00
// On Windows, the library never identifies files as block, character, fifo
[libcxx] Document windows specifics regarding file_type and perms. NFC. This was requested in the review of D98138. Differential Revision: https://reviews.llvm.org/D98155
2021-03-08 05:49:56 +08:00
// 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
};
[libcxx] Document windows specifics regarding file_type and perms. NFC. This was requested in the review of D98138. Differential Revision: https://reviews.llvm.org/D98155
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;
};
[libc++] s/_LIBCPP_NO_HAS_CHAR8_T/_LIBCPP_HAS_NO_CHAR8_T/g This was raised in D94511. Differential Revision: https://reviews.llvm.org/D100736
2021-04-19 09:47:08 +08:00
#ifndef _LIBCPP_HAS_NO_CHAR8_T
[libcxx] Implement c++2a char8_t input/output of std::filesystem::path This implements the std::filesystem parts of P0482 (which is already marked as in progress), and applies the actions that are suggested in P1423. Differential Revision: https://reviews.llvm.org/D90222
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) {
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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('/');
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
2020-10-27 19:09:08 +08:00
#endif
Fix even more Clang warnings. This patch disables shift-sign-overflow warnings for now. It also fixes most -Wfloat-equal warnings and -Wextra-semi warnings. llvm-svn: 343438
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
[libc++] s/_LIBCPP_NO_HAS_CHAR8_T/_LIBCPP_HAS_NO_CHAR8_T/g This was raised in D94511. Differential Revision: https://reviews.llvm.org/D100736
2021-04-19 09:47:08 +08:00
#ifndef _LIBCPP_HAS_NO_CHAR8_T
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
2020-10-27 19:09:08 +08:00
typedef u8string __u8_string;
#else
typedef string __u8_string;
#endif
[libcxx] Fix typo in spelling of 'sentinel'. NFC. Differential Revision: https://reviews.llvm.org/D90220
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*;
[libcxx] Fix typo in spelling of 'sentinel'. NFC. Differential Revision: https://reviews.llvm.org/D90220
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;
[libcxx] Fix typo in spelling of 'sentinel'. NFC. Differential Revision: https://reviews.llvm.org/D90220
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; }
};
Rename __is_foo_iterator traits to reflect their Cpp17 nature. With the upcoming introduction of iterator concepts in ranges, the meaning of "__is_contiguous_iterator" changes drastically. Currently we intend it to mean "does it have this iterator category", but it could now also mean "does it meet the requirements of this concept", and these can be different.
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; }
[libcxx] Fix typo in spelling of 'sentinel'. NFC. Differential Revision: https://reviews.llvm.org/D90220
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> {};
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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
[libcxx] Convert paths to/from the right narrow code page for narrow strings on windows On windows, the narrow, char based paths normally don't use utf8, but can use many different native code pages, and this is what system functions that operate on files, taking such paths/file names, interpret them as. Differential Revision: https://reviews.llvm.org/D91137
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
[libc++] Add a libc++ configuration that does not support localization When porting libc++ to embedded systems, it can be useful to drop support for localization, which these systems don't implement or care about. Differential Revision: https://reviews.llvm.org/D90072
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;
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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) {
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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);
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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>
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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);
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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());
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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>
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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");
[libcxx] Fix typo in spelling of 'sentinel'. NFC. Differential Revision: https://reviews.llvm.org/D90220
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;
[libcxx] Fix typo in spelling of 'sentinel'. NFC. Differential Revision: https://reviews.llvm.org/D90220
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);
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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());
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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>
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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));
}
};
[libc++] Add a libc++ configuration that does not support localization When porting libc++ to embedded systems, it can be useful to drop support for localization, which these systems don't implement or care about. Differential Revision: https://reviews.llvm.org/D90072
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 <>
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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>
Rename __is_foo_iterator traits to reflect their Cpp17 nature. With the upcoming introduction of iterator concepts in ranges, the meaning of "__is_contiguous_iterator" changes drastically. Currently we intend it to mean "does it have this iterator category", but it could now also mean "does it meet the requirements of this concept", and these can be different.
2019-11-18 14:46:58 +08:00
static typename enable_if<__is_exactly_cpp17_input_iterator<_Iter>::value>::type
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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>
Rename __is_foo_iterator traits to reflect their Cpp17 nature. With the upcoming introduction of iterator concepts in ranges, the meaning of "__is_contiguous_iterator" changes drastically. Currently we intend it to mean "does it have this iterator category", but it could now also mean "does it meet the requirements of this concept", and these can be different.
2019-11-18 14:46:58 +08:00
static typename enable_if<__is_cpp17_forward_iterator<_Iter>::value>::type
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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>
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
2020-10-27 19:09:08 +08:00
static void __append_range(__path_string& __dest, _Iter __b, _NullSentinel) {
[libcxx] Fix typo in spelling of 'sentinel'. NFC. Differential Revision: https://reviews.llvm.org/D90220
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>
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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));
}
};
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
2020-10-27 19:09:08 +08:00
#if defined(_LIBCPP_WIN32API)
[libcxx] Convert paths to/from the right narrow code page for narrow strings on windows On windows, the narrow, char based paths normally don't use utf8, but can use many different native code pages, and this is what system functions that operate on files, taking such paths/file names, interpret them as. Differential Revision: https://reviews.llvm.org/D91137
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));
}
};
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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());
}
};
[libcxx] Convert paths to/from the right narrow code page for narrow strings on windows On windows, the narrow, char based paths normally don't use utf8, but can use many different native code pages, and this is what system functions that operate on files, taking such paths/file names, interpret them as. Differential Revision: https://reviews.llvm.org/D91137
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);
}
};
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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());
}
};
[libc++] s/_LIBCPP_NO_HAS_CHAR8_T/_LIBCPP_HAS_NO_CHAR8_T/g This was raised in D94511. Differential Revision: https://reviews.llvm.org/D100736
2021-04-19 09:47:08 +08:00
#ifndef _LIBCPP_HAS_NO_CHAR8_T
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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());
}
};
[libc++] s/_LIBCPP_NO_HAS_CHAR8_T/_LIBCPP_HAS_NO_CHAR8_T/g This was raised in D94511. Differential Revision: https://reviews.llvm.org/D100736
2021-04-19 09:47:08 +08:00
#endif /* !_LIBCPP_HAS_NO_CHAR8_T */
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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:
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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 = '/';
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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
[libcxx] Make path::format a non-class enum The spec doesn't declare it as an enum class, and being declared as an enum class breaks referring to the values as e.g. path::auto_format. Differential Revision: https://reviews.llvm.org/D97084
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);
}
Raise compile error when using unimplemented functions The path functions in this patch are unimplemented (as per the TODO comment from upstream). To avoid running into a linker error (missing symbol), this patch raises a compile error by commenting out the functions, which is more user friendly. Differential Revision: https://reviews.llvm.org/D111892
2021-10-21 01:55:50 +08:00
/*
[libc++] Add a libc++ configuration that does not support localization When porting libc++ to embedded systems, it can be useful to drop support for localization, which these systems don't implement or care about. Differential Revision: https://reviews.llvm.org/D90072
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);
[libc++] Add a libc++ configuration that does not support localization When porting libc++ to embedded systems, it can be useful to drop support for localization, which these systems don't implement or care about. Differential Revision: https://reviews.llvm.org/D90072
2020-10-10 03:31:05 +08:00
#endif
Raise compile error when using unimplemented functions The path functions in this patch are unimplemented (as per the TODO comment from upstream). To avoid running into a linker error (missing symbol), this patch raises a compile error by commenting out the functions, which is more user friendly. Differential Revision: https://reviews.llvm.org/D111892
2021-10-21 01:55:50 +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
_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;
}
[libc++] Remove the ability to use braced-init for filesystem paths According to my reading of http://eel.is/c++draft/filesystems#fs.class.path, the Standard doesn't actually mention that this should work. Since other implementations don't allow it, allowing it in libc++ is just setting a portability trap. Supersedes https://reviews.llvm.org/D89865. Differential Revision: https://reviews.llvm.org/D95975
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
[libcxx] Implement append and operator/ properly for windows The root_path function has to be changed to return the parsed bit as-is; otherwise a path like "//net" gets a root path of "//net/", as the root name, "//net", gets the root directory (an empty string) appended, forming "//net/". (The same doesn't happen for the root dir "c:" though.) Differential Revision: https://reviews.llvm.org/D91178
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();
[libcxx] Avoid intermediate string objects for substrings in windows operator/= Check that appends with a path object doesn't do allocations, even on windows. Suggested by Marek in D98398. The patch might apply without D98398 (depending on how much of the diff context has to match), but doesn't make much sense until after that patch has landed. Differential Revision: https://reviews.llvm.org/D98412
2021-03-11 19:06:08 +08:00
__pn_ += __string_view(__p.__pn_).substr(__p_root_name_size);
[libcxx] Implement append and operator/ properly for windows The root_path function has to be changed to return the parsed bit as-is; otherwise a path like "//net" gets a root path of "//net/", as the root name, "//net", gets the root directory (an empty string) appended, forming "//net/". (The same doesn't happen for the root dir "c:" though.) Differential Revision: https://reviews.llvm.org/D91178
2020-11-04 21:59:56 +08:00
return *this;
}
if (has_filename() || (!has_root_directory() && is_absolute()))
__pn_ += preferred_separator;
[libcxx] Avoid intermediate string objects for substrings in windows operator/= Check that appends with a path object doesn't do allocations, even on windows. Suggested by Marek in D98398. The patch might apply without D98398 (depending on how much of the diff context has to match), but doesn't make much sense until after that patch has landed. Differential Revision: https://reviews.llvm.org/D98412
2021-03-11 19:06:08 +08:00
__pn_ += __string_view(__p.__pn_).substr(__p_root_name_size);
[libcxx] Implement append and operator/ properly for windows The root_path function has to be changed to return the parsed bit as-is; otherwise a path like "//net" gets a root path of "//net/", as the root name, "//net", gets the root directory (an empty string) appended, forming "//net/". (The same doesn't happen for the root dir "c:" though.) Differential Revision: https://reviews.llvm.org/D91178
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> >;
[libcxx] Implement append and operator/ properly for windows The root_path function has to be changed to return the parsed bit as-is; otherwise a path like "//net" gets a root path of "//net/", as the root name, "//net", gets the root directory (an empty string) appended, forming "//net/". (The same doesn't happen for the root dir "c:" though.) Differential Revision: https://reviews.llvm.org/D91178
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>;
[libcxx] Implement append and operator/ properly for windows The root_path function has to be changed to return the parsed bit as-is; otherwise a path like "//net" gets a root path of "//net/", as the root name, "//net", gets the root directory (an empty string) appended, forming "//net/". (The same doesn't happen for the root dir "c:" though.) Differential Revision: https://reviews.llvm.org/D91178
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;
}
[libcxx] Implement append and operator/ properly for windows The root_path function has to be changed to return the parsed bit as-is; otherwise a path like "//net" gets a root path of "//net/", as the root name, "//net", gets the root directory (an empty string) appended, forming "//net/". (The same doesn't happen for the root dir "c:" though.) Differential Revision: https://reviews.llvm.org/D91178
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) {
[libc++] [docs] Mark LWG3055 as complete. Use string_view instead of string in path::operator+=(ECharT). The issue didn't change the behaviour which is tested in libcxx/test/std/input.output/filesystems/class.path/path.member/path.concat.pass.cpp. The change to use string_view instead of string is not strictly necessary. <filesystem> was added in commit 998a5c88312066fcc2b2de1358edc76587611354 (Implement <filesystem>). Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D92731
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(); }
[libcxx] Handle backslash as path separator on windows Differential Revision: https://reviews.llvm.org/D91138
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_; }
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
2020-10-27 19:09:08 +08:00
#if defined(_LIBCPP_WIN32API)
_LIBCPP_INLINE_VISIBILITY _VSTD::wstring wstring() const { return __pn_; }
[libcxx] Make generic_*string return paths with forward slashes on windows This matches what MS STL returns; in std::filesystem, forward slashes are considered generic dir separators that are valid on all platforms. Differential Revision: https://reviews.llvm.org/D91181
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;
}
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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 {
[libcxx] Convert paths to/from the right narrow code page for narrow strings on windows On windows, the narrow, char based paths normally don't use utf8, but can use many different native code pages, and this is what system functions that operate on files, taking such paths/file names, interpret them as. Differential Revision: https://reviews.llvm.org/D91137
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;
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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 {
[libcxx] Make generic_*string return paths with forward slashes on windows This matches what MS STL returns; in std::filesystem, forward slashes are considered generic dir separators that are valid on all platforms. Differential Revision: https://reviews.llvm.org/D91181
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;
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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>(); }
[libcxx] Make generic_*string return paths with forward slashes on windows This matches what MS STL returns; in std::filesystem, forward slashes are considered generic dir separators that are valid on all platforms. Differential Revision: https://reviews.llvm.org/D91181
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;
}
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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_; }
[libc++] s/_LIBCPP_NO_HAS_CHAR8_T/_LIBCPP_HAS_NO_CHAR8_T/g This was raised in D94511. Differential Revision: https://reviews.llvm.org/D100736
2021-04-19 09:47:08 +08:00
#ifndef _LIBCPP_HAS_NO_CHAR8_T
[libcxx] Implement c++2a char8_t input/output of std::filesystem::path This implements the std::filesystem parts of P0482 (which is already marked as in progress), and applies the actions that are suggested in P1423. Differential Revision: https://reviews.llvm.org/D90222
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_; }
[libcxx] Implement c++2a char8_t input/output of std::filesystem::path This implements the std::filesystem parts of P0482 (which is already marked as in progress), and applies the actions that are suggested in P1423. Differential Revision: https://reviews.llvm.org/D90222
2020-10-26 19:18:46 +08:00
#endif
[libc++] Add a libc++ configuration that does not support localization When porting libc++ to embedded systems, it can be useful to drop support for localization, which these systems don't implement or care about. Differential Revision: https://reviews.llvm.org/D90072
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++] Add an option to disable wide character support in libc++ Some embedded platforms do not wish to support the C library functionality for handling wchar_t because they have no use for it. It makes sense for libc++ to work properly on those platforms, so this commit adds a carve-out of functionality for wchar_t. Unfortunately, unlike some other carve-outs (e.g. random device), this patch touches several parts of the library. However, despite the wide impact of this patch, I still think it is important to support this configuration since it makes it much simpler to port libc++ to some embedded platforms. Differential Revision: https://reviews.llvm.org/D111265
2021-08-24 03:32:36 +08:00
#ifndef _LIBCPP_HAS_NO_WIDE_CHARACTERS
[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++] Add an option to disable wide character support in libc++ Some embedded platforms do not wish to support the C library functionality for handling wchar_t because they have no use for it. It makes sense for libc++ to work properly on those platforms, so this commit adds a carve-out of functionality for wchar_t. Unfortunately, unlike some other carve-outs (e.g. random device), this patch touches several parts of the library. However, despite the wide impact of this patch, I still think it is important to support this configuration since it makes it much simpler to port libc++ to some embedded platforms. Differential Revision: https://reviews.llvm.org/D111265
2021-08-24 03:32:36 +08:00
#endif
[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>();
}
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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_; }
[libc++] s/_LIBCPP_NO_HAS_CHAR8_T/_LIBCPP_HAS_NO_CHAR8_T/g This was raised in D94511. Differential Revision: https://reviews.llvm.org/D100736
2021-04-19 09:47:08 +08:00
#ifndef _LIBCPP_HAS_NO_CHAR8_T
[libcxx] Implement c++2a char8_t input/output of std::filesystem::path This implements the std::filesystem parts of P0482 (which is already marked as in progress), and applies the actions that are suggested in P1423. Differential Revision: https://reviews.llvm.org/D90222
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_; }
[libcxx] Implement c++2a char8_t input/output of std::filesystem::path This implements the std::filesystem parts of P0482 (which is already marked as in progress), and applies the actions that are suggested in P1423. Differential Revision: https://reviews.llvm.org/D90222
2020-10-26 19:18:46 +08:00
#endif
[libc++] Add a libc++ configuration that does not support localization When porting libc++ to embedded systems, it can be useful to drop support for localization, which these systems don't implement or care about. Differential Revision: https://reviews.llvm.org/D90072
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++] Add an option to disable wide character support in libc++ Some embedded platforms do not wish to support the C library functionality for handling wchar_t because they have no use for it. It makes sense for libc++ to work properly on those platforms, so this commit adds a carve-out of functionality for wchar_t. Unfortunately, unlike some other carve-outs (e.g. random device), this patch touches several parts of the library. However, despite the wide impact of this patch, I still think it is important to support this configuration since it makes it much simpler to port libc++ to some embedded platforms. Differential Revision: https://reviews.llvm.org/D111265
2021-08-24 03:32:36 +08:00
#ifndef _LIBCPP_HAS_NO_WIDE_CHARACTERS
[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>(); }
[libc++] Add an option to disable wide character support in libc++ Some embedded platforms do not wish to support the C library functionality for handling wchar_t because they have no use for it. It makes sense for libc++ to work properly on those platforms, so this commit adds a carve-out of functionality for wchar_t. Unfortunately, unlike some other carve-outs (e.g. random device), this patch touches several parts of the library. However, despite the wide impact of this patch, I still think it is important to support this configuration since it makes it much simpler to port libc++ to some embedded platforms. Differential Revision: https://reviews.llvm.org/D111265
2021-08-24 03:32:36 +08:00
#endif
[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::u16string generic_u16string() const { return string<char16_t>(); }
_VSTD::u32string generic_u32string() const { return string<char32_t>(); }
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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 {
[libcxx] Implement append and operator/ properly for windows The root_path function has to be changed to return the parsed bit as-is; otherwise a path like "//net" gets a root path of "//net/", as the root name, "//net", gets the root directory (an empty string) appended, forming "//net/". (The same doesn't happen for the root dir "c:" though.) Differential Revision: https://reviews.llvm.org/D91178
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()));
[libcxx] Implement append and operator/ properly for windows The root_path function has to be changed to return the parsed bit as-is; otherwise a path like "//net" gets a root path of "//net/", as the root name, "//net", gets the root directory (an empty string) appended, forming "//net/". (The same doesn't happen for the root dir "c:" though.) Differential Revision: https://reviews.llvm.org/D91178
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 {
[libcxx] Implement is_absolute properly for windows Differential Revision: https://reviews.llvm.org/D91177
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();
[libcxx] Implement is_absolute properly for windows Differential Revision: https://reviews.llvm.org/D91177
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;
[libc++] Add a libc++ configuration that does not support localization When porting libc++ to embedded systems, it can be useful to drop support for localization, which these systems don't implement or care about. Differential Revision: https://reviews.llvm.org/D90072
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
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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
[libcxx] Make filesystem::path::value_type wchar_t on windows Also set the preferred separator to backslash. libc++ doesn't compile successfully for windows prior to this change, and this change on its own isn't enough to make it compile successfully either, but is the first stepping stone towards making it work correctly. Most of operations.cpp will need to be touched, both for calling functions that take wchar paths, but also for using other windows specific functions instead of the posix functions used so far; that is handled in later commits. Changing parts of operations.cpp to generalize the string type handling in code that doesn't touch system functions. Differential Revision: https://reviews.llvm.org/D91135
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;
}
[libc++] Add a libc++ configuration that does not support localization When porting libc++ to embedded systems, it can be useful to drop support for localization, which these systems don't implement or care about. Differential Revision: https://reviews.llvm.org/D90072
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
Implement LWG 3065: Make path operators friends. This prevents things like: using namespace std::filesystem; auto x = L"a/b" == std::string("a/b"); llvm-svn: 349884
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>
[libcxx] Implement c++2a char8_t input/output of std::filesystem::path This implements the std::filesystem parts of P0482 (which is already marked as in progress), and applies the actions that are suggested in P1423. Differential Revision: https://reviews.llvm.org/D90222
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(
[libc++] s/_LIBCPP_NO_HAS_CHAR8_T/_LIBCPP_HAS_NO_CHAR8_T/g This was raised in D94511. Differential Revision: https://reviews.llvm.org/D100736
2021-04-19 09:47:08 +08:00
#ifndef _LIBCPP_HAS_NO_CHAR8_T
[libcxx] Implement c++2a char8_t input/output of std::filesystem::path This implements the std::filesystem parts of P0482 (which is already marked as in progress), and applies the actions that are suggested in P1423. Differential Revision: https://reviews.llvm.org/D90222
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,
[libcxx] Implement c++2a char8_t input/output of std::filesystem::path This implements the std::filesystem parts of P0482 (which is already marked as in progress), and applies the actions that are suggested in P1423. Differential Revision: https://reviews.llvm.org/D90222
2020-10-26 19:18:46 +08:00
"u8path(Iter, Iter) requires Iter have a value_type of type 'char'"
[libcxx] Remove ifdefs in the message to static_assert. NFC. Differential Revision: https://reviews.llvm.org/D93283
2020-12-15 15:15:37 +08:00
" or 'char8_t'");
[libcxx] Convert paths to/from the right narrow code page for narrow strings on windows On windows, the narrow, char based paths normally don't use utf8, but can use many different native code pages, and this is what system functions that operate on files, taking such paths/file names, interpret them as. Differential Revision: https://reviews.llvm.org/D91137
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);
[libcxx] Convert paths to/from the right narrow code page for narrow strings on windows On windows, the narrow, char based paths normally don't use utf8, but can use many different native code pages, and this is what system functions that operate on files, taking such paths/file names, interpret them as. Differential Revision: https://reviews.llvm.org/D91137
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
}
[libcxx] Convert paths to/from the right narrow code page for narrow strings on windows On windows, the narrow, char based paths normally don't use utf8, but can use many different native code pages, and this is what system functions that operate on files, taking such paths/file names, interpret them as. Differential Revision: https://reviews.llvm.org/D91137
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(
[libc++] s/_LIBCPP_NO_HAS_CHAR8_T/_LIBCPP_HAS_NO_CHAR8_T/g This was raised in D94511. Differential Revision: https://reviews.llvm.org/D100736
2021-04-19 09:47:08 +08:00
#ifndef _LIBCPP_HAS_NO_CHAR8_T
[libcxx] Convert paths to/from the right narrow code page for narrow strings on windows On windows, the narrow, char based paths normally don't use utf8, but can use many different native code pages, and this is what system functions that operate on files, taking such paths/file names, interpret them as. Differential Revision: https://reviews.llvm.org/D91137
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 */
[libcxx] Reorder the two u8path functions, to make the following diff more readable. NFC. Differential Revision: https://reviews.llvm.org/D91136
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(
[libc++] s/_LIBCPP_NO_HAS_CHAR8_T/_LIBCPP_HAS_NO_CHAR8_T/g This was raised in D94511. Differential Revision: https://reviews.llvm.org/D100736
2021-04-19 09:47:08 +08:00
#ifndef _LIBCPP_HAS_NO_CHAR8_T
[libcxx] Reorder the two u8path functions, to make the following diff more readable. NFC. Differential Revision: https://reviews.llvm.org/D91136
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'");
[libcxx] Convert paths to/from the right narrow code page for narrow strings on windows On windows, the narrow, char based paths normally don't use utf8, but can use many different native code pages, and this is what system functions that operate on files, taking such paths/file names, interpret them as. Differential Revision: https://reviews.llvm.org/D91137
2020-10-27 19:30:34 +08:00
#if defined(_LIBCPP_WIN32API)
using _Traits = __is_pathable<_Source>;
[libc++] Rationalize our treatment of contiguous iterators and __unwrap_iter(). - Implement C++20's changes to `reverse_iterator`, so that it won't be accidentally counted as a contiguous iterator in C++20 mode. - Implement C++20's changes to `move_iterator` as well. - `move_iterator` should not be contiguous. This fixes a bug where we optimized `std::copy`-of-move-iterators in an observable way. Add a regression test for that bugfix. - Add libcxx tests for `__is_cpp17_contiguous_iterator` of all relevant standard iterator types. Particularly check that vector::iterator is still considered contiguous in all C++ modes, even C++03. After this patch, there continues to be no supported way to write your own iterator type in C++17-and-earlier such that libc++ will consider it "contiguous"; however, we now fully support the C++20 approach (in C++20 mode only). If you want user-defined contiguous iterators in C++17-and-earlier, libc++'s position is "please upgrade to C++20." Differential Revision: https://reviews.llvm.org/D94807
2021-01-16 01:59:56 +08:00
return u8path(_VSTD::__unwrap_iter(_Traits::__range_begin(__s)), _VSTD::__unwrap_iter(_Traits::__range_end(__s)));
[libcxx] Convert paths to/from the right narrow code page for narrow strings on windows On windows, the narrow, char based paths normally don't use utf8, but can use many different native code pages, and this is what system functions that operate on files, taking such paths/file names, interpret them as. Differential Revision: https://reviews.llvm.org/D91137
2020-10-27 19:30:34 +08:00
#else
[libcxx] Reorder the two u8path functions, to make the following diff more readable. NFC. Differential Revision: https://reviews.llvm.org/D91136
2020-11-05 06:21:30 +08:00
return path(__s);
[libcxx] Convert paths to/from the right narrow code page for narrow strings on windows On windows, the narrow, char based paths normally don't use utf8, but can use many different native code pages, and this is what system functions that operate on files, taking such paths/file names, interpret them as. Differential Revision: https://reviews.llvm.org/D91137
2020-10-27 19:30:34 +08:00
#endif
[libcxx] Reorder the two u8path functions, to make the following diff more readable. NFC. Differential Revision: https://reviews.llvm.org/D91136
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);
}
[libc++] Mark <filesystem> as unavailable on Apple platforms using pragmas Summary: Also add the corresponding XFAILs to tests that require filesystem. The approach taken to mark <filesystem> as unavailable in this patch is to mark all the header as unavailable using #pragma clang attribute. Marking each declaration using the attribute is more intrusive and does not provide a lot of value right now because pretty much everything in <filesystem> requires dylib support, often transitively. This is an alternative to https://reviews.llvm.org/D59093. A similar (but partial) patch was already applied in r356558. Reviewers: mclow.lists, EricWF, serge-sans-paille Subscribers: christof, jkorous, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D59224 llvm-svn: 356616
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_; }
Fix -Wdeprecated-copy-dtor and -Wdeprecated-dynamic-exception-spec warnings. Summary: The former are like: libcxx/include/typeinfo:322:11: warning: definition of implicit copy constructor for 'bad_cast' is deprecated because it has a user-declared destructor [-Wdeprecated-copy-dtor] virtual ~bad_cast() _NOEXCEPT; ^ libcxx/include/typeinfo:344:11: note: in implicit copy constructor for 'std::bad_cast' first required here throw bad_cast(); ^ Fix these by adding an explicitly defaulted copy constructor. The latter are like: libcxx/include/codecvt:105:37: warning: dynamic exception specifications are deprecated [-Wdeprecated-dynamic-exception-spec] virtual int do_encoding() const throw(); ^~~~~~~ Fix these by using the _NOEXCEPT macro instead. Reviewers: EricWF, mclow.lists, ldionne, #libc Reviewed By: EricWF, #libc Subscribers: dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D76150
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:
[libc++] Mark internal types of std::filesystem as hidden Summary: Otherwise, implicit instantiations of templates with these types can cause the dylib to start exporting the vtable/RTTI of the instantiation. Giving hidden visibility to those types causes the compiler to understand that they are not used outside the dylib, and as a result implicitly instantiated vtables/RTTI of templates with those internal types will get hidden visibility. Reviewers: EricWF Subscribers: christof, jkorous, dexonsmith, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59550 llvm-svn: 356488
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_;
};
[libc++] Mark <filesystem> as unavailable on Apple platforms using pragmas Summary: Also add the corresponding XFAILs to tests that require filesystem. The approach taken to mark <filesystem> as unavailable in this patch is to mark all the header as unavailable using #pragma clang attribute. Marking each declaration using the attribute is more intrusive and does not provide a lot of value right now because pretty much everything in <filesystem> requires dylib support, often transitively. This is an alternative to https://reviews.llvm.org/D59093. A similar (but partial) patch was already applied in r356558. Reviewers: mclow.lists, EricWF, serge-sans-paille Subscribers: christof, jkorous, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D59224 llvm-svn: 356616
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
[NFC][libc++] Reindent function llvm-svn: 353180
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
[NFC][libc++] Reindent function llvm-svn: 353180
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;
[libc++] Mark internal types of std::filesystem as hidden Summary: Otherwise, implicit instantiations of templates with these types can cause the dylib to start exporting the vtable/RTTI of the instantiation. Giving hidden visibility to those types causes the compiler to understand that they are not used outside the dylib, and as a result implicitly instantiated vtables/RTTI of templates with those internal types will get hidden visibility. Reviewers: EricWF Subscribers: christof, jkorous, dexonsmith, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59550 llvm-svn: 356488
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
[libc++] LWG3480: make (recursive_)directory_iterator C++20 ranges Implement LWG3480 which enables `directory_iterator` and `recursive_directory_iterator` to be both a `borrowed_range` and a `view`. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D111644
2021-10-14 23:53:43 +08:00
end(directory_iterator) 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
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:
[libc++] Always build with -fvisibility=hidden Summary: This avoids symbols being accidentally exported from the dylib when they shouldn't. The next step is to use a pragma to apply hidden visibility to all declarations (unless otherwise specified), which will allow us to drop the per-declaration hidden visibility attributes we currently have. This also has the nice side effect of making sure the dylib exports the same symbols regardless of the optimization level. PR38138 Reviewers: EricWF, mclow.lists Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D62868 llvm-svn: 368703
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;
[libc++] Mark internal types of std::filesystem as hidden Summary: Otherwise, implicit instantiations of templates with these types can cause the dylib to start exporting the vtable/RTTI of the instantiation. Giving hidden visibility to those types causes the compiler to understand that they are not used outside the dylib, and as a result implicitly instantiated vtables/RTTI of templates with those internal types will get hidden visibility. Reviewers: EricWF Subscribers: christof, jkorous, dexonsmith, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59550 llvm-svn: 356488
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
[libc++] LWG3480: make (recursive_)directory_iterator C++20 ranges Implement LWG3480 which enables `directory_iterator` and `recursive_directory_iterator` to be both a `borrowed_range` and a `view`. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D111644
2021-10-14 23:53:43 +08:00
end(recursive_directory_iterator) 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
return recursive_directory_iterator();
}
[libc++] Mark <filesystem> as unavailable on Apple platforms using pragmas Summary: Also add the corresponding XFAILs to tests that require filesystem. The approach taken to mark <filesystem> as unavailable in this patch is to mark all the header as unavailable using #pragma clang attribute. Marking each declaration using the attribute is more intrusive and does not provide a lot of value right now because pretty much everything in <filesystem> requires dylib support, often transitively. This is an alternative to https://reviews.llvm.org/D59093. A similar (but partial) patch was already applied in r356558. Reviewers: mclow.lists, EricWF, serge-sans-paille Subscribers: christof, jkorous, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D59224 llvm-svn: 356616
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
[libc++] LWG3480: make (recursive_)directory_iterator C++20 ranges Implement LWG3480 which enables `directory_iterator` and `recursive_directory_iterator` to be both a `borrowed_range` and a `view`. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D111644
2021-10-14 23:53:43 +08:00
#if !defined(_LIBCPP_HAS_NO_RANGES)
template <>
inline constexpr bool _VSTD::ranges::enable_borrowed_range<_VSTD_FS::directory_iterator> = true;
template <>
inline constexpr bool _VSTD::ranges::enable_borrowed_range<_VSTD_FS::recursive_directory_iterator> = true;
template <>
inline constexpr bool _VSTD::ranges::enable_view<_VSTD_FS::directory_iterator> = true;
template <>
inline constexpr bool _VSTD::ranges::enable_view<_VSTD_FS::recursive_directory_iterator> = true;
#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
#endif // !_LIBCPP_CXX03_LANG
_LIBCPP_POP_MACROS
#endif // _LIBCPP_FILESYSTEM