Summary:
In the CHERI clang compiler __output and __input are keywords and therefore
we can't compile libc++ with our compiler.
Reviewers: mclow.lists, EricWF, theraven
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D39537
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@318144 91177308-0d34-0410-b5e6-96231b3b80d8
LWG 3013 points out that the constructors and increment members
of the directory iterators need to allocate, and therefore cannot
be marked noexcept.
It also points out that `is_empty` and `copy` likely need to allocate
as well, and as such can also not be noexcept.
This patch speculatively implements the resolution removing noexcept,
because libc++ does indeed have the possibility of throwing on allocation
failure.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@316941 91177308-0d34-0410-b5e6-96231b3b80d8
It seems conceivable that a user would need to get a coroutine handle
having only a const reference to the promise_type, for example from
within a const member function of the promise.
This patch allows that use case. A coroutine_handle<const T> can be used
in essentially the same way a coroutine_handle<T>, ie to start and destroy
the coroutine. The constness of the promise doesn't/shouldn't propagate
to the handle.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@305536 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch improves how libc++ handles min/max macros within the headers. Previously libc++ would undef them and emit a warning.
This patch changes libc++ to use `#pragma push_macro` to save the macro before undefining it, and `#pragma pop_macro` to restore the macros and the end of the header.
Reviewers: mclow.lists, bcraig, compnerd, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D33080
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@304357 91177308-0d34-0410-b5e6-96231b3b80d8
from_address requires that the provided pointer refer to the suspended coroutine,
which doesn't have a type, or at least not one knowable by the user. Therefore
every use of `from_address` with a typed pointer is almost certainly a bug.
This behavior is a part of the TS specification, but hopefully it will be
in the future.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@304172 91177308-0d34-0410-b5e6-96231b3b80d8
More tests to come. I think that from_address overload should be deleted
or ill-formed, except for the 'void*' one; The user cannot possibly
have a typed pointer to the coroutine state.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@304131 91177308-0d34-0410-b5e6-96231b3b80d8
Clang supports coroutines in all dialects; Therefore libc++ should too,
otherwise the Clang extension is unusable.
I'm not convinced extending support to C++03 is a feasible long term
plan, since as the library grows to offer things like generators it
will be come increasingly difficult to limit the implementation to C++03.
However for the time being supporting C++03 isn't a big deal.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@303963 91177308-0d34-0410-b5e6-96231b3b80d8
Clang started providing -fcoroutines and defining __cpp_coroutines
way before it implemented the __builtin_coro_foo functions. This
means that simply checking if __cpp_coroutines is not a sufficient
way of detecting the actual feature.
This patch implements _LIBCPP_HAS_NO_COROUTINES which implements
a slightly more complex feature check. Specifically it requires
__cpp_coroutines >= 201703L, which only holds for Clang 5.0 built
after 2017/05/24.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@303956 91177308-0d34-0410-b5e6-96231b3b80d8
The original issues were caused because <experimental/coroutine>
didn't correctly #ifdef out enough of the header, which caused incomplete
types to be used.
This patch fixes the `#if defined(__cpp_coroutines)` guard and re-adds
the headers to the module map.
It also uglifies some incorrectly non-reserved names.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@303936 91177308-0d34-0410-b5e6-96231b3b80d8
This patch updates the promise() member to match the current spec.
Specifically it removes the non-const overload and make the return
type of the const overload non-const.
This patch also makes the ASSERT_NOT_NOEXCEPT tests libc++ specific,
since other implementations may be free to strengthen the specification.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@303895 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes the test failures and unexpected passes that occur
when testing against GCC 7. Specifically:
* don't mark __gcd as always inline because it's a recursive function. GCC diagnoses this.
* don't XFAIL the aligned allocation tests. GCC 7 supports them but not the -faligned-allocation option.
* Work around gcc.gnu.org/PR78489 in variants constructors.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@302488 91177308-0d34-0410-b5e6-96231b3b80d8
Libc++ is used as a system library on macOS and iOS (amongst others). In order
for users to be able to compile a binary that is intended to be deployed to an
older version of the platform, clang provides the
availability attribute <https://clang.llvm.org/docs/AttributeReference.html#availability>_
that can be placed on declarations to describe the lifecycle of a symbol in the
library.
See docs/DesignDocs/AvailabilityMarkup.rst for more information.
Differential Revision: https://reviews.llvm.org/D31739
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@302172 91177308-0d34-0410-b5e6-96231b3b80d8
path::iterator isn't a strictly conforming iterator. Specifically
it stashes the current element inside the iterator. This leads to
UB when used with reverse_iterator since it requires the element
to outlive the lifetime of the iterator.
This patch adds a static_assert inside reverse_iterator to disallow
"stashing iterator types", and it tags path::iterator as such a type.
Additionally this patch removes all uses of reverse_iterator<path::iterator>
within the tests.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@300164 91177308-0d34-0410-b5e6-96231b3b80d8
These member functions were decorated with `_LIBCPP_FUNC_VIS` when the
class is also decorated with external visibility. This breaks down when
building for PE/COFF, where the member function cannot be decorated if
it is within a decorated class. The class attribute will propagate to
the member. Remove the extraneous decoration.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@293454 91177308-0d34-0410-b5e6-96231b3b80d8
Microsoft's SAL has a `__deref` macro which results in a compilation
failure when building the filesystem module on Windows. Rename the
member function internally to avoid the conflict.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@293449 91177308-0d34-0410-b5e6-96231b3b80d8
Adding `path::operator=(string_type&&)` made the expression `p = {}`
ambiguous. This path fixes that ambiguity by making the `string&&`
overload a template so it ranks lower during overload resolution.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@292345 91177308-0d34-0410-b5e6-96231b3b80d8
Windows is greedy and it defines the identifier `__out` as a macro.
This patch renames all conflicting libc++ identifiers in order
to correctly work on Windows.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@291345 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
On Windows the identifier `__deallocate` is defined as a macro by one of the Windows system headers. Previously libc++ worked around this by `#undef __deallocate` and generating a warning. However this causes the WIN32 version of `__threading_support` to always generate a warning on Windows. This is not OK.
This patch renames all usages of `__deallocate` internally as to not conflict with the macro.
Reviewers: mclow.lists, majnemer, rnk, rsmith, smeenai, compnerd
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28426
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@291332 91177308-0d34-0410-b5e6-96231b3b80d8
The name _LIBCPP_TYPE_VIS_ONLY is no longer accurate because both
_LIBCPP_TYPE_VIS and _LIBCPP_TYPE_VIS_ONLY expand to
__attribute__((__type_visibility__)) with Clang. The only remaining difference
is that _LIBCPP_TYPE_VIS_ONLY can be applied to templates whereas
_LIBCPP_TYPE_VIS cannot (due to dllimport/dllexport not being allowed on
templates).
This patch renames _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@291035 91177308-0d34-0410-b5e6-96231b3b80d8
In the previous fix I used a PMF type as a semi-safe bool type in C++03.
However immediately after committing I realized clang offered explicit
conversion operators as an extension. This patch removes the old fix and
enables _LIBCPP_EXPLICIT using __has_extension instead.
This change also affects the following other classes, which have
'_LIBCPP_EXPLICIT operator bool()'.
* shared_ptr
* unique_ptr
* error_condition
* basic_ios
* function (already C++11 only)
* istream::sentry
* experimental::string_view.
In all of the above cases I believe it is safe to enable the extension, except
in the experimental::string_view case. There seem to be some Clang bugs
affecting the experimental::string_view conversion to std::basic_string. To
work around that I manually disabled _LIBCPP_EXPLICIT in that case.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290831 91177308-0d34-0410-b5e6-96231b3b80d8
path uses string::append to construct, append, and concatenate paths. Unfortunatly
string::append has a strong exception safety guaranteed and if it can't prove
that the iterator operations don't throw then it will allocate a temporary
string copy to append to. However this extra allocation and copy is very
undesirable for path which doesn't have the same exception guarantees.
To work around this this patch adds string::__append_forward_unsafe which exposes
the std::string::append interface for forward iterators without enforcing
that the iterator is noexcept.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@285532 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes a performance bug when constructing or appending to a path
from a string or c-string. Previously we called 'push_back' to append every
single character. This caused multiple re-allocation and copies when at most
one reallocation is necessary. The new behavior is to simply call
`string::append` so it can correctly handle reallocation.
For large strings this change is a ~4x improvement. This also makes our path
faster to construct than libstdc++'s.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@285530 91177308-0d34-0410-b5e6-96231b3b80d8
This patch entirely rewrites the parsing logic for paths. Unlike the previous
implementation this one stores information about the current state; For example
if we are in a trailing separator or a root separator. This avoids the need for
extra lookahead (and extra work) when incrementing or decrementing an iterator.
Roughly this gives us a 15% speedup over the previous implementation.
Unfortunately this implementation is still a lot slower than libstdc++'s.
Because libstdc++ pre-parses and splits the path upon construction their
iterators are trivial to increment/decrement. This makes libc++ lazy parsing
100x slower than libstdc++. However the pre-parsing libstdc++ causes a ton
of extra and unneeded allocations when constructing the string. For example
`path("/foo/bar/")` would require at least 5 allocations with libstdc++
whereas libc++ uses only one. The non-allocating behavior is much preferable
when you consider filesystem usages like 'exists("/foo/bar/")'.
Even then libc++'s path seems to be twice as slow to simply construct compared
to libstdc++. More investigation is needed about this.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@285526 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch fixes a number of problems with the visibility macros across GCC (on Unix) and Windows (DLL import/export semantics). All of the visibility macros are now documented under `DesignDocs/VisibilityMacros.rst`. Now I'll no longer forget the subtleties of each!
This patch adds two new visibility macros:
* `_LIBCPP_ENUM_VIS` for controlling the typeinfo of enum types. Only Clang supports this.
* `_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS` for redefining visibility on explicit instantiation declarations. Clang and Windows require this.
After applying this patch GCC only emits one -Wattribute warning opposed to 30+.
Reviewers: mclow.lists, EricWF
Subscribers: beanz, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D24602
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@281673 91177308-0d34-0410-b5e6-96231b3b80d8
