Summary:
This patch attempts to re-implement a fix for LWG 2770, but not the actual specified PR.
The PR for 2770 specifies tuple_size<T const> as only conditionally providing a `::value` member. However C++17 structured bindings require `tuple_size<T const>` to be complete only if `tuple_size<T>` is also complete. Therefore this patch implements only provides the specialization `tuple_size<T CV>` iff `tuple_size<T>` is a complete type.
This fixes http://llvm.org/PR31513.
Reviewers: mclow.lists, rsmith, mpark
Subscribers: mpark, cfe-commits
Differential Revision: https://reviews.llvm.org/D28222
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@291019 91177308-0d34-0410-b5e6-96231b3b80d8
A typo and missing header inclusion was obscured by the litany of user
defined literal warnings. This fixes the detection of ELAST on windows.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290941 91177308-0d34-0410-b5e6-96231b3b80d8
MSVC 19+ and clang-cl with emulation version >= 19.00 will provide
char{16,32}_t as builtin types. Adjust the configuration accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290940 91177308-0d34-0410-b5e6-96231b3b80d8
Use the cmake variables to get the platform dependent values for the
static library prefix and suffix, which can be different from the Unix
preference for "lib", ".a" (e.g. Windows uses "", ".lib" respectively).
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290939 91177308-0d34-0410-b5e6-96231b3b80d8
Use `CMAKE_LIBRARY_PATH_FLAG` instead of hard-coding it to -L. This
silences a warning with cl which expects `/LIBPATH` instead.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290938 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce a `_LIBCPP_HAS_BITSCAN64` macro to specify if the 64-bit
variant of the bitscan family of APIs is available. This avoids
duplicating the check in the support header.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290924 91177308-0d34-0410-b5e6-96231b3b80d8
These tests were using malloc()'s return value without checking for null,
which MSVC's /analyze rightly warns about. Asserting that the pointer is
non-null both expresses the test's intention and silences the warning.
Fixes D27785.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290921 91177308-0d34-0410-b5e6-96231b3b80d8
Replace the use of _WIN32 in libc++. Replace most use with a C runtime
check _LIBCPP_MSVCRT or the new _LIBCPP_WIN32 to indicate that we are
using the Win32 API. Use a new _LIBCPP_WCHAR_IS_UCS2 to indicate that we
are on an environment that has a short wchar_t.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290910 91177308-0d34-0410-b5e6-96231b3b80d8
after r290850
Before r290850, building libcxx with -DLIBCXX_HAS_EXTERNAL_THREAD_API=ON had two
uses:
- Allow platform vendors to plug-in an __external_threading header which
should take care of the entire threading infrastructure of libcxx
- Allow testing of an externally-threaded library build; where the thread API
is declared using pthread data structures, and the implementation of this
API is provided as a separate library (test/support/external_threads.cpp)
and linked-in when running the test suite.
r290850 breaks the second use case (pthread data structures are no longer
available). This patch re-stores the ability to build+test an
externally-threaded library variant on a pthread based system.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290878 91177308-0d34-0410-b5e6-96231b3b80d8
Update the configuration to reflect the style more accurately. Pointers
are tied to the left. Braces are split on classes/structs and
functions.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290857 91177308-0d34-0410-b5e6-96231b3b80d8
THe previous change replaced the use of `cat` or `type` with a custom
python script. Remove the now unused command determining.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290856 91177308-0d34-0410-b5e6-96231b3b80d8
Refactor the header to allow us to implement alternate threading models
with alternate data structures. Take the opportunity to clang-format
the area. This will allow us to avoid re-declaring the interfaces for
Win32 threading. NFC
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290850 91177308-0d34-0410-b5e6-96231b3b80d8
This patch re-commits a previous attempt to support building libc++ w/o
an ABI library. That patch was originally reverted because:
1) It forgot to teach the test suite about "default" ABI libraries.
2) Some LLVM builders don't clear the CMake cache between builds. The previous
patch caused those builders to fail since their old cache entry for
LIBCXX_CXX_ABI="" is no longer valid.
The updated patch addresses both issues. It works around (2) by adding
a hack to force the builders to update their cache entries. The hack will
be removed shortly once all LLVM builders have run.
Original commit message
-----------------------
Typically libc++ uses libc++abi or libcxxrt to provide the ABI and runtime bits
of the C++ STL. However we also support building w/o an ABI library entirely.
This patch fixes building libc++ w/o an ABI library (and incorporates the
`~type_info()` fix in D28211).
The main changes in this patch are:
1) Add `-DLIBCXX_CXX_ABI=default` instead of using the empty string to mean "default".
2) Fix CMake bits which treated "none" as "default" on OS X.
3) Teach the source files to respect `-D_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY`.
4) Define ~type_info() when _LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY is defined.
Unfortunately this patch doesn't help clean up the macro mess that we use to
configure for different ABI libraries.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290849 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements the correct PR for LWG 2770. It also makes the primary
tuple_size template incomplete again which fixes part of llvm.org/PR31513.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290846 91177308-0d34-0410-b5e6-96231b3b80d8
Currently libc++ compiles a special version of error_category()
into the dylib. This definition is no longer needed, and doesn't
work on Windows due to dllimport/dllexport semantics.
For those reasons this patch introduces an option to
disable/enable this definition. By default the definition
is provided in ABI v1 except on windows. This patch
also addresses D28210.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290840 91177308-0d34-0410-b5e6-96231b3b80d8
Typically libc++ uses libc++abi or libcxxrt to provide the ABI and runtime bits
of the C++ STL. However we also support building w/o an ABI library entirely.
This patch fixes building libc++ w/o an ABI library (and incorporates the
`~type_info()` fix in D28211).
The main changes in this patch are:
1) Add `-DLIBCXX_CXX_ABI=default` instead of using the empty string to mean "default".
2) Fix CMake bits which treated "none" as "default" on OS X.
3) Teach the source files to respect `-D_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY`.
4) Define ~type_info() when _LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY is defined.
Unfortunately this patch doesn't help clean up the macro mess that we use to
configure for different ABI libraries.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290839 91177308-0d34-0410-b5e6-96231b3b80d8
Move the windows specific macro definitions for compiling c++ into the
target. Add a number of newer options that are necessary to properly
build libc++ for windows. This ensures that we do not accidentally
autolink msvcprt (Microsoft's C++ runtime library), do not define linker
pragmas which are msvcprt specific, and do not accidentally encode the
incorrect version of the msvc compatibility version.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290837 91177308-0d34-0410-b5e6-96231b3b80d8
Disable the manifest bundling on Windows when cross-compiling on
not-Windows. With this, it is possible to execute the link command from
CMake which will use cmake to invoke the manifest tool to generate a
manifest and pass that to the linker.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290836 91177308-0d34-0410-b5e6-96231b3b80d8
The locale structures have been made opaque in CRT 14+. This currently
prevents building libc++ for Windows. We can re-enable this in the
future when we have replicated the structure to access the private field
for the name (unless there exists a better supported mechanism to query
the name of a locale given the locale_t).
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290835 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
As pointed out by Howard, this is actually 134774 days (* 24 * 3600),
and therefore seconds, not 100ns units. Adjust the units to reflect
reality.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290824 91177308-0d34-0410-b5e6-96231b3b80d8
Visual C++ 14 and newer split msvcrt into msvcrt and ucrt with flavours
of the ucrt for different environments. This changed the access to the
ctype table by introducing the `__pctype_func` and `__pwctype_func`
accessors. Use this rather than directly accessing `_ctype` which
allows us to be safer in threaded situations by going through the libc
locking.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290823 91177308-0d34-0410-b5e6-96231b3b80d8
Drawing some inspiration from code from Bill O'Neal as pointed out by
Howard, rework the code to avoid an overflow in the duration. Adjust
the style to match libc++ style as well.
Create a local typedef for the FILETIME duration (100-ns units). Use
this to define the difference between the NT and the UNIX epochs (which
previously overflowed due to the representation limits due to the
bouncing to ns). Return the FILETIME duration biased by the NT-to-UNIX
epoch conversion.
Use of the custom duration makes it easier to read and reason about the
code.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290806 91177308-0d34-0410-b5e6-96231b3b80d8
system_clock::now is not entirely straight forward on Windows, which
does not have a clock_gettime function.
GetSystemTimeAsFileTime gives us the value relative to the NT epoch (Jan
1 1601) rather than the Unix epoch (Jan 1 1970). However, this function
has a low resolution (~10ms). Newer versions of Windows provide
GetSystemTimePreciseAsFileTime which gives us a much more accurate time
(<1us). Unfortunately, the latter is only available on Windows 8+ when
targeting desktop apps.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290803 91177308-0d34-0410-b5e6-96231b3b80d8
This allows us to build with cl (or rather clang-cl) by using the
correct spelling for `-include` (`/FI` for cl). clang-cl and cl default
to C++11/C++14 as they support it rather than permitting an explicit
language standard.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290802 91177308-0d34-0410-b5e6-96231b3b80d8
Hard code the defaults for Windows for the time being. The checks
really are always going to return the same value. Technically, the
pthread linkage is possible, however, it seems better to use the Win32
threading along with the external threading support that we have added.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290801 91177308-0d34-0410-b5e6-96231b3b80d8
This is necessary to support cross-compiling a Windows libc++ from
Linux. The CMAKE_SYSTEM_HOST_NAME tells you what, in autotools
parlance, is known as the build as opposed to WIN32 which maps to, in
autotools parlance, host.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290800 91177308-0d34-0410-b5e6-96231b3b80d8
When building libc++ without threading, strerror_r is not used. Define
the code only when threading is enabled. This allows us to build
system_error for Windows, which ATM doesn't build with threading.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290791 91177308-0d34-0410-b5e6-96231b3b80d8
These exception types are marked with `_LIBCPP_EXCEPTION_ABI` which
expands to `__attribute__((__visibility__("default")))` or
`__declspec(dllexport)`. When building for Windows, we would hit an
error:
cannot apply 'dllexport' to a 'dllexport' class
Remove the duplicate annotations as they will be inherited from the
class.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290785 91177308-0d34-0410-b5e6-96231b3b80d8
We need to include __config to ensure that we know what random
implementation is being used. Fixes compilation for Windows.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290775 91177308-0d34-0410-b5e6-96231b3b80d8
There were two problems with the initial fix.
1. The added tests flushed out that we misconfigured _LIBCPP_EXPLICIT with GCC.
2. Because the boolean type was a member function template it caused weird link
errors. I'm assuming due to the vague linkage rules. This time the bool type
is a non-template member function pointer. That seems to have fixed the
failing tests. Plus it will end up generating less symbols overall, since
the bool type is no longer per instantiation.
original commit message below
-----------------------------
std::basic_ios has an operator bool(). In C++11 and later
it is explicit, and only allows contextual implicit conversions.
However explicit isn't available in C++03 which causes std::istream (et al)
to have an implicit conversion to int. This can easily cause ambiguities
when calling operator<< and operator>>.
This patch uses a "bool-like" type in C++03 to work around this. The
"bool-like" type is an arbitrary pointer to member function type. It
will not convert to either int or void*, but will convert to bool.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290754 91177308-0d34-0410-b5e6-96231b3b80d8
std::basic_ios has an operator bool(). In C++11 and later
it is explicit, and only allows contextual implicit conversions.
However explicit isn't available in C++03 which causes std::istream (et al)
to have an implicit conversion to int. This can easily cause ambiguities
when calling operator<< and operator>>.
This patch uses a "bool-like" type in C++03 to work around this. The
"bool-like" type is an arbitrary pointer to member function type. It
will not convert to either int or void*, but will convert to bool.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290750 91177308-0d34-0410-b5e6-96231b3b80d8
Back in r240527 I added a knob to prevent thread-unsafe functions from
being exposed. mblen(), mbtowc() and wctomb() were also added to this
list, as the latest issue of POSIX doesn't require these functions to be
thread-safe.
It turns out that the only circumstance in which these functions are not
thread-safe is in case they are used in combination with state-dependent
character sets (e.g., Shift-JIS). According to Austin Group Bug 708,
these character sets "[...] are mostly a relic of the past and which
were never supported on most POSIX systems".
Though in many cases the use of these functions can be prevented by
using the reentrant counterparts, they are the only functions that allow
you to query whether the locale's character set is state-dependent. This
means that omitting these functions removes actual functionality.
Let's be a bit less pedantic and drop the guards around these functions.
Links:
http://austingroupbugs.net/view.php?id=708http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2037.htm
Reviewed by: ericwf
Differential Revision: https://reviews.llvm.org/D21436
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290748 91177308-0d34-0410-b5e6-96231b3b80d8
