The specification of this function mandates a cast to uninitialized
T*, which is forbidden under CFI.
Differential Revision: https://reviews.llvm.org/D42146
llvm-svn: 322744
Inline the provided "fallback" definitions (which seem to always be
taken) that expand to __cdecl into users. The fallback definitions
for the *CRTIMP* macros were wrong in the case where the CRT is being
linked statically, so define our own macro as a replacement.
Differential Revision: https://reviews.llvm.org/D42158
llvm-svn: 322617
type 'result_type' to 'double'. The only thing that we ever do with
these numbers is to promote them to 'double' and use them in a division.
For small result_types, the values were getting truncated, skewing the
results. Thanks to James Nagurne for the suggestion.
llvm-svn: 322556
It covers the cases when the sentry object returns false and when an exception
was thrown. Corresponding standard paragraph is C++14 [istream.unformatted]p9:
[...] In any case, if n is greater than zero it then stores a null
character into the next successive location of the array.
rdar://problem/35566567
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40677
llvm-svn: 322326
An application may determine whether the C standard library is glibc
by testing whether __GLIBC_PREREQ is defined. This breaks if libc++
provides its own definition. Instead, define our own macro in our
namespace with the desired semantics.
Differential Revision: https://reviews.llvm.org/D41892
llvm-svn: 322201
Seems to have broken some tests since I first wrote this a while
back. Will reland after checking what went wrong with the tests.
This reverts commit 7023194c8d11a081fd01ed25308b3d60193c6a06.
llvm-svn: 322039
Summary:
After rL319736 for D28253 (which fixes PR28929), gcc cannot compile `<memory>` anymore in pre-C+11 modes, complaining:
```
In file included from /usr/include/c++/v1/memory:648:0,
from test.cpp:1:
/usr/include/c++/v1/memory: In static member function 'static std::__1::shared_ptr<_Tp> std::__1::shared_ptr<_Tp>::make_shared(_A0&, _A1&, _A2&)':
/usr/include/c++/v1/memory:4365:5: error: wrong number of template arguments (4, should be at least 1)
static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't construct object in make_shared" );
^
In file included from /usr/include/c++/v1/memory:649:0,
from test.cpp:1:
/usr/include/c++/v1/type_traits:3198:29: note: provided for 'template<class _Tp, class _A0, class _A1> struct std::__1::is_constructible'
struct _LIBCPP_TEMPLATE_VIS is_constructible
^~~~~~~~~~~~~~~~
In file included from /usr/include/c++/v1/memory:648:0,
from test.cpp:1:
/usr/include/c++/v1/memory:4365:5: error: template argument 1 is invalid
static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't construct object in make_shared" );
^
/usr/include/c++/v1/memory: In static member function 'static std::__1::shared_ptr<_Tp> std::__1::shared_ptr<_Tp>::allocate_shared(const _Alloc&, _A0&, _A1&, _A2&)':
/usr/include/c++/v1/memory:4444:5: error: wrong number of template arguments (4, should be at least 1)
static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't construct object in allocate_shared" );
^
In file included from /usr/include/c++/v1/memory:649:0,
from test.cpp:1:
/usr/include/c++/v1/type_traits:3198:29: note: provided for 'template<class _Tp, class _A0, class _A1> struct std::__1::is_constructible'
struct _LIBCPP_TEMPLATE_VIS is_constructible
^~~~~~~~~~~~~~~~
In file included from /usr/include/c++/v1/memory:648:0,
from test.cpp:1:
/usr/include/c++/v1/memory:4444:5: error: template argument 1 is invalid
static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't construct object in allocate_shared" );
^
```
This is also reported in https://bugs.freebsd.org/224946 (FreeBSD is apparently one of the very few projects that regularly builds programs against libc++ with gcc).
The reason is that the static assertions are invoking `is_constructible` with three arguments, while gcc does not have the built-in `is_constructible` feature, and the pre-C++11 `is_constructible` wrappers in `<type_traits>` only provide up to two arguments.
I have added additional wrappers for three arguments, modified the `is_constructible` entry point to take three arguments instead, and added a simple test to is_constructible.pass.cpp.
Reviewers: EricWF, mclow.lists
Reviewed By: EricWF
Subscribers: krytarowski, cfe-commits, emaste
Differential Revision: https://reviews.llvm.org/D41805
llvm-svn: 321963
This allows keeping libcxx using win32 threads even if a
version of pthread.h is installed.
This matches the existing cmake option LIBCXX_HAS_PTHREAD_API.
Also add missing documentation about the internal define
_LIBCPP_HAS_THREAD_API_WIN32.
Differential Revision: https://reviews.llvm.org/D41764
llvm-svn: 321896
As a result of this change, the basic_stringbuf constructor that
takes a mode ends up leaving __hm_ set to 0, causing the comparison
"__hm_ - __str_.data() < __noff" in seekoff() to succeed, which caused
the function to incorrectly return -1. The fix is to account for the
possibility of __hm_ being 0 when computing the distance from __hm_
to the start of the string.
Differential Revision: https://reviews.llvm.org/D41319
llvm-svn: 321124
It turns out that this is the only change required in libcxx
for it to compile with the new `wasm32-unknown-unknown-wasm`
target recently added to Clang.
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D41073
llvm-svn: 320925
Summary:
[libcxx] Fix basic_stringbuf constructor
The C++ Standard [stringbuf.cons]p1 defines the effects of the basic_stringbuf
constructor that takes ios_base::openmode as follows:
Effects: Constructs an object of class basic_stringbuf, initializing the
base class with basic_streambuf(), and initializing mode with which.
Postconditions: str() == "".
The default constructor of basic_streambuf shall initialize all its
pointer member objects to null pointers [streambuf.cons]p1.
Currently libc++ calls "str(string_type());" in the aforementioned constructor
setting basic_streambuf's pointers to a non-null value.
This patch removes the call (note that the postcondition str() == ""
remains valid because __str_ is default-initialized) and adds a test checking
that the basic_streambuf's pointers are null after construction.
Thanks Mikhail Maltsev for the patch.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40707
llvm-svn: 320604
Summary:
Introduce a new form of `result_of` without function type encoding.
Rename and split `is_callable/is_nothrow_callable` into `is_invocable/is_nothrow_invocable/is_invocable_r/is_nothrow_invocable_r` (and associated types accordingly)
Change function type encoding of previous `is_callable/is_nothrow_callable` traits to conventional template type parameter lists.
Reviewers: EricWF, mclow.lists, bebuch
Reviewed By: EricWF, bebuch
Subscribers: lichray, bebuch, cfe-commits
Differential Revision: https://reviews.llvm.org/D38831
llvm-svn: 320509
Currently libc++ defines operator== and operator!= as friend functions in the
definition of the istream_iterator class template. Such definition has a subtle
difference from an out-of-line definition required by the C++ Standard: these
functions can only be found by argument-dependent lookup, but not by qualified
lookup.
This patch changes the definition, so that it conforms to the C++ Standard and
adds a check involving qualified lookup to the test suite.
Patch contributed by Mikhail Maltsev.
Differential Revision: https://reviews.llvm.org/D40415
llvm-svn: 320363
These buildbots are using the deprecated target name install-libcxx-headers
instead of the more up to date install-cxx-headers, so I need to add an
install-libcxx-headers-stripped target to satisfy them.
llvm-svn: 320201
LLVM is gaining install-*-stripped targets to perform stripped installs,
and in order for this to be useful for install-distribution, all
potential distribution components should have stripped installation
targets. LLVM has a function to create these install targets, but since
we can't use LLVM CMake functions in libc++, let's do it manually.
Differential Revision: https://reviews.llvm.org/D40680
llvm-svn: 319959
The MSVC driver and clang do not link against the C++ runtime
explicitly. Instead, they rely on the auto-linking via the pragma
(through `use_ansi.h`) to link against the correct version of the C++
runtime. Attempt to do something similar here so that linking real C++
code on Windows does not require the user to explicitly specify
`c++.lib` when using libc++ as a C++ runtime on windows.
llvm-svn: 319816
The parameter was previously renamed but MSVC path was not updated.
Patch by Andrey Khalyavin.
Differential Revision: https://reviews.llvm.org/D40774
llvm-svn: 319802
Use this source use on Fuchsia where this is the oficially way
to obtain randomness. This could be also used on other platforms
that already support getentropy such as *BSD or Linux.
Differential Revision: https://reviews.llvm.org/D40319
llvm-svn: 319523
Fix the problem PR31516 with setting locale on Windows by wrapping
_locale_t with a pointer-like class.
Reduces 74 test failures in std/localization test suite to 47 test
failures (on llvm clang, Visual Studio 2015). Number of test failures
doesn't depend on the platform (x86 or x64).
Patch by Andrey Khalyavin.
Differential Revision: https://reviews.llvm.org/D40181
llvm-svn: 318902
It covers the cases when the sentry object returns false and when an exception
was thrown. Corresponding standard paragraph is C++14 [istream.unformatted]p21:
In any case, if n is greater than zero, it then stores a null character
(using charT()) into the next successive location of the array.
Patch by Reimar Döffinger.
llvm-svn: 318862
One can't replace vsscanf(_l) with a sscanf(_l) that doesn't
take a va_list.
This has been untouched since it was added in SVN r140728, so
apparently it hasn't been used since. One reason for this mistake
originally might have been that there was no _vsscanf_l until MSVC
2015.
Since it's unused, just remove this define.
Differential Revision: https://reviews.llvm.org/D40323
llvm-svn: 318810
The non-const data() member of std::string is only exposed
in C++17 and beyond. However std::string is externally instantiated
and so the member function needs to be exposed to be externally instantiated.
On Linux and OS X this shouldn't cause a problem, because
_LIBCPP_INLINE_VISIBILITY ensures the symbol is always inlined.
However on Windows, the symbol gets marked dllimport, but
there is no definition to import, causing link errors.
llvm-svn: 318690
Summary:
Currently `std::variant` always uses an unsigned int to store the variant index. However this isn't nessesary and causes `std::variant` to be larger than it needs to be in most cases.
This patch changes the index type to be `unsigned char` when possible, and `unsigned short` or `unsigned int` otherwise, depending on the size (Although it's questionable if it's even possible to create a variant with 65535 elements.
Unfortunately this change is an ABI break, and as such is only enabled in ABI v2.
Reviewers: mpark
Reviewed By: mpark
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40210
llvm-svn: 318621
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
llvm-svn: 318144
The commit r300140 changed the implementation of compressed_pair, but didn't add
_LIBCPP_INLINE_VISIBILITY to the constructors and get members of the
compressed_pair_elem class. This patch adds the visibility annotation.
I didn't find a way to test this change with libc++ regression tests.
rdar://35352579
Differential Revision: https://reviews.llvm.org/D39751
llvm-svn: 317816
Summary:
quick_exit() and at_quick_exit() were introduced in android NDK 21:
https://android.googlesource.com/platform/prebuilts/ndk/+/dev/platform/sysroot/usr/include/stdlib.h#55
This CL conditions `_LIBCPP_HAS_QUICK_EXIT` on `__ANDROID_API__ >= 21`. The only place this macro is used is in some using declarations: `using ::quick_exit`, `using ::at_quick_exit`.
Also, add a missing include to sys/cdefs.h which is what defines `__BIONIC__`.
Reviewers: thakis, danalbert, EricWF
Reviewed By: danalbert
Subscribers: srhines, krytarowski
Differential Revision: https://reviews.llvm.org/D39479
llvm-svn: 317124
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.
llvm-svn: 316941
The logic to allocate a node within std::list was repeated
in a bunch of places. This is unneeded. This patch refactors
the shared logic into a single function to reduce duplication.
This patch is part of a set to clean up node construction in
general, but refactoring construction requires some more work
to make it work cleanly in C++03
llvm-svn: 316021
Previously this macro used 0/1 to indicate if it was set.
This is unlike all other libc++ configuration macros which
use ifdef/ifndef.
This patch makes this macro consistent with everything else.
llvm-svn: 315995
Summary:
The constructors `vector(Iter, Iter, Alloc = Alloc{})` and `assign(Iter, Iter)` don't correctly perform EmplaceConstruction from the result of dereferencing the iterator. This results in them performing an additional and unneeded copy.
This patch addresses the issue by correctly using `emplace_back` in C++11 and newer.
There are also some bugs in our `insert` implementation, but those will be handled separately.
@mclow.lists We should probably merge this into 5.1, agreed?
Reviewers: mclow.lists, dlj, EricWF
Reviewed By: mclow.lists, EricWF
Subscribers: cfe-commits, mclow.lists
Differential Revision: https://reviews.llvm.org/D38757
llvm-svn: 315994
The vcruntime headers are hairy and clash with both libc++ headers
themselves and other libraries. libc++ normally deals with the clashes
by deferring to the vcruntime headers and silencing its own definitions,
but for clients which don't want to depend on vcruntime headers, it's
desirable to support the opposite, i.e. have libc++ provide its own
definitions.
Certain operator new/delete replacement scenarios are not currently
supported in this mode, which requires some tests to be marked XFAIL.
The added documentation has more details.
Differential Revision: https://reviews.llvm.org/D38522
llvm-svn: 315234
Make it clear that these are intended only to force a specific ABI when
the autodetection would give the wrong result by renaming the cmake
options and adding separate forcing macros, as suggested by EricWF in
the post-commit review of r314949 and further discussed on IRC.
llvm-svn: 314965
libc++'s current heuristic for detecting Itanium vs. Microsoft ABI falls
short in some cases. For example, it will detect windows-itanium targets
as using the Microsoft ABI, since they set `_MSC_VER` (for compatibility
with Microsoft headers). Leave the current heuristic in place by default
but also allow users to explicitly specify the ABI if need be.
llvm-svn: 314949
Some ABI macros affect headers, so it's nice to have a site config
option for them. Add a LIBCXX_ABI_DEFINES cmake macro to allow
specifying a list of ABI macros to define in the site config.
The primary design constraint (as discussed with Eric on IRC a while
back) was to not have to repeat the ABI macro names in cmake, which only
leaves a free-form cmake list as an option. A somewhat unfortunate
consequence is that we can't verify that the ABI macros being defined
actually exist, though we can at least perform some basic sanity
checking, since all the ABI macros begin with _LIBCPP_ABI_.
Differential Revision: https://reviews.llvm.org/D36719
llvm-svn: 314946
Microsoft's CRT already provides the const overloads, and it defines the
`_CRT_CONST_CORRECT_OVERLOADS` macro to indicate their presence. Check
for this macro before attempting to define our own const-correct
overloads, to avoid compiler warnings about casts dropping const
qualifiers.
llvm-svn: 313377
The RTTI structure is different on Windows when building under MS ABI.
Update the definition to reflect this. The structure itself contains an
area for caching the undecorated name (which is 0-initialized). The
decorated name has a bitfield followed by the linkage name. When
std::type_info::name is invoked for the first time, the runtime should
undecorate the name, cache it, and return the undecorated name. This
requires access to an implementation of __unDName. For now, return
the raw name.
This uses the fnv-1a hash to hash the name of the RTTI. We could use an
alternate hash (murmur? city?), but, this was the quickest to throw
together.
llvm-svn: 313344
Marshall Clow