Summary:
AIX system headers need stdint.h and inttypes.h to be re-enterable when macro _STD_TYPES_T is defined so that limit macro definitions such as UINT32_MAX can be found. This patch attempts to allow that on AIX.
Reviewers: hubert.reinterpretcast, jasonliu, mclow.lists, EricWF
Reviewed by: hubert.reinterpretcast, mclow.lists
Subscribers: jfb, jsji, christof, cfe-commits, libcxx-commits, llvm-commits
Tags: #LLVM, #clang, #libc++
Differential Revision: https://reviews.llvm.org/D59253
llvm-svn: 363939
Summary:
All overloads of `::abs` and `std::abs` must be present in both `<cmath>` and `<cstdlib>`. This is problematic to implement because C defines `fabs` in `math.h` and `labs` in `stdlib.h`. This introduces a circular dependency between the two headers.
This patch implements that requirement by moving `abs` into `math.h` and making `stdlib.h` include `math.h`. In order to get the underlying C declarations from the "real" `stdlib.h` inside our `math.h` we need some trickery. Specifically we need to make `stdlib.h` include next itself.
Suggestions for a cleaner implementation are welcome.
Reviewers: mclow.lists, ldionne
Reviewed By: ldionne
Subscribers: krytarowski, fedor.sergeev, dexonsmith, jdoerfert, jsji, libcxx-commits
Differential Revision: https://reviews.llvm.org/D60097
llvm-svn: 359020
Summary:
In r342843, I added deprecation warnings to some facilities that were
deprectated in C++14 and C++17. However, those deprecation warnings
were not enabled by default.
After discussing this on IRC, we had finally gotten consensus to enable
those warnings by default, and I'm getting around to doing that only
now.
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D58140
llvm-svn: 355961
Summary:
Some implementations of fenv.h use macros to define the functions they provide. This can cause problems when `std::fegetround()` is spelled in source.
This patch adds a `fenv.h` header to libc++ for the sole purpose of turning those macros into real functions.
Reviewers: rsmith, mclow.lists, ldionne
Reviewed By: rsmith
Subscribers: mgorny, christof, libcxx-commits
Differential Revision: https://reviews.llvm.org/D57729
llvm-svn: 353767
Summary:
Freestanding is *weird*. The standard allows it to differ in a bunch of odd
manners from regular C++, and the committee would like to improve that
situation. I'd like to make libc++ behave better with what freestanding should
be, so that it can be a tool we use in improving the standard. To do that we
need to try stuff out, both with "freestanding the language mode" and
"freestanding the library subset".
Let's start with the super basic: run the libc++ tests in freestanding, using
clang as the compiler, and see what works. The easiest hack to do this:
In utils/libcxx/test/config.py add:
self.cxx.compile_flags += ['-ffreestanding']
Run the tests and they all fail.
Why? Because in freestanding `main` isn't special. This "not special" property
has two effects: main doesn't get mangled, and main isn't allowed to omit its
`return` statement. The first means main gets mangled and the linker can't
create a valid executable for us to test. The second means we spew out warnings
(ew) and the compiler doesn't insert the `return` we omitted, and main just
falls of the end and does whatever undefined behavior (if you're luck, ud2
leading to non-zero return code).
Let's start my work with the basics. This patch changes all libc++ tests to
declare `main` as `int main(int, char**` so it mangles consistently (enabling us
to declare another `extern "C"` main for freestanding which calls the mangled
one), and adds `return 0;` to all places where it was missing. This touches 6124
files, and I apologize.
The former was done with The Magic Of Sed.
The later was done with a (not quite correct but decent) clang tool:
https://gist.github.com/jfbastien/793819ff360baa845483dde81170feed
This works for most tests, though I did have to adjust a few places when e.g.
the test runs with `-x c`, macros are used for main (such as for the filesystem
tests), etc.
Once this is in we can create a freestanding bot which will prevent further
regressions. After that, we can start the real work of supporting C++
freestanding fairly well in libc++.
<rdar://problem/47754795>
Reviewers: ldionne, mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, arphaman, miyuki, libcxx-commits
Differential Revision: https://reviews.llvm.org/D57624
llvm-svn: 353086
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
This is a revert of r347421, except I'm using the with_system_cxx_lib
lit feature instead of availability to mark the test as unsupported
(because the problem is a bug in the dylib itself). In r347421, I said
I wasn't able to reproduce the issue and that's why I was removing it:
this was because I ran lit slightly wrong. The problem mentioned really
exists.
llvm-svn: 347475
I wasn't able to reproduce the issue referred to by the comment using
the libc++'s shipped with mac OS X 10.7 and 10.8, so I assume this may
have been fixed in a function that is now shipped in the headers. In
that case, the tests will pass no matter what dylib we're using.
In the worst case, some test bots will start failing and I'll understand
why I was wrong, and I can create an actual lit feature for it. Note
that I could just leave this test alone, but this change is on the path
towards eradicating vendor-specific availability markup from the test
suite.
llvm-svn: 347421
The test is trying to avoid saying aligned_alloc on Windows' UCRT, which does not (and can not) implement aligned_alloc. However, it's testing for c1xx, meaning clang on Windows will fail this test when using the UCRT.
llvm-svn: 344829
Debian build bots are running Clang 4, which apparently does not support
the "deprecated" attribute properly. Clang pretends to support the attribute,
but the attribute doesn't do anything.
(live example: https://wandbox.org/permlink/0De69aXns0t1D59r)
On a separate note, I'm not sure I understand why we're even running the
libc++ tests under Clang-4. Is this a configuration we support? I can
understand that libc++ should _build_ with Clang 4, but it's not clear
to me that new libc++ headers should be usable under older compilers
like that.
llvm-svn: 342854
Summary:
These deprecation warnings are opt-in: they are only enabled when the
_LIBCXX_DEPRECATION_WARNINGS macro is defined, which is not the case
by default. Note that this is a first step in the right direction, but
I wasn't able to get an exhaustive list of all deprecated components
per standard, so there's certainly stuff that's missing. The list of
components this commit marks as deprecated is:
in C++11:
- auto_ptr, auto_ptr_ref
- binder1st, binder2nd, bind1st(), bind2nd()
- pointer_to_unary_function, pointer_to_binary_function, ptr_fun()
- mem_fun_t, mem_fun1_t, const_mem_fun_t, const_mem_fun1_t, mem_fun()
- mem_fun_ref_t, mem_fun1_ref_t, const_mem_fun_ref_t, const_mem_fun1_ref_t, mem_fun_ref()
in C++14:
- random_shuffle()
in C++17:
- unary_negate, binary_negate, not1(), not2()
<rdar://problem/18168350>
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D48912
llvm-svn: 342843
Summary:
Those tests are breaking the test bots. A Bugzilla has been filed to
make sure those tests are re-enabled: https://bugs.llvm.org/show_bug.cgi?id=38572
Reviewers: mclow.lists, EricWF
Subscribers: krytarowski, christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D50748
llvm-svn: 339742
Summary:
These #includes are quite important, since otherwise any
#if TEST_STD_VER > 14 && defined(TEST_HAS_C11_FEATURES)
checks are always false, and so we don't actually test for C11 support
in the standard library.
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D50674
llvm-svn: 339675
test/std/containers/Emplaceable.h
test/std/containers/NotConstructible.h
test/support/counting_predicates.hpp
Replace unary_function/binary_function inheritance with typedefs.
test/std/depr/depr.function.objects/depr.base/binary_function.pass.cpp
test/std/depr/depr.function.objects/depr.base/unary_function.pass.cpp
test/std/utilities/function.objects/func.require/binary_function.pass.cpp
test/std/utilities/function.objects/func.require/unary_function.pass.cpp
Mark these tests as requiring 98/03/11/14 because 17 removed unary_function/binary_function.
test/std/thread/futures/futures.task/futures.task.members/ctor_func_alloc.pass.cpp
test/std/thread/futures/futures.task/futures.task.nonmembers/uses_allocator.pass.cpp
Mark these tests as requiring 11/14 because 17 removed packaged_task allocator support.
test/std/utilities/function.objects/func.wrap/func.wrap.func/derive_from.pass.cpp
This test doesn't need to be skipped in C++17 mode. Only the construction of
std::function from an allocator needs to be skipped in C++17 mode.
test/std/utilities/function.objects/refwrap/refwrap.access/conversion.pass.cpp
test/std/utilities/function.objects/refwrap/refwrap.assign/copy_assign.pass.cpp
test/std/utilities/function.objects/refwrap/refwrap.const/copy_ctor.pass.cpp
test/std/utilities/function.objects/refwrap/refwrap.const/type_ctor.pass.cpp
When testing these reference_wrapper features, unary_function inheritance is totally irrelevant.
test/std/utilities/function.objects/refwrap/weak_result.pass.cpp
Define and use my_unary_function/my_binary_function to test the weak result type machinery
(which is still present in C++17, although deprecated).
test/support/msvc_stdlib_force_include.hpp
Now we can test C++17 strictly, without enabling removed features.
Fixes D36503.
llvm-svn: 311705
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
llvm-svn: 302172
Summary:
This patch implements [P0003R5](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0003r5.html) which removes exception specifications from C++17.
The only changes to the library are removing `set_unexpected`, `get_unexpected`, `unexpected`, and `unexpected_handler`. These functions can be re-enabled in C++17 using `_LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS`.
@mclow.lists what do you think about removing stuff is this way?
Reviewers: mclow.lists
Reviewed By: mclow.lists
Subscribers: mclow.lists, cfe-commits
Differential Revision: https://reviews.llvm.org/D28172
llvm-svn: 295406
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
llvm-svn: 290748
test/std/depr/depr.c.headers/inttypes_h.pass.cpp
test/std/input.output/file.streams/c.files/cinttypes.pass.cpp
test/std/input.output/iostream.forward/iosfwd.pass.cpp
Add test() to avoid a bunch of void-casts, although we still need a few.
test/std/input.output/iostream.format/quoted.manip/quoted.pass.cpp
skippingws was unused (it's unclear to me whether this was mistakenly copy-pasted from round_trip() below).
test/std/localization/locale.categories/category.collate/locale.collate/types.pass.cpp
test/std/localization/locale.categories/category.ctype/facet.ctype.special/types.pass.cpp
test/std/localization/locale.categories/category.ctype/locale.codecvt/types_char.pass.cpp
test/std/localization/locale.categories/category.ctype/locale.codecvt/types_wchar_t.pass.cpp
test/std/localization/locale.categories/category.ctype/locale.ctype/types.pass.cpp
test/std/localization/locale.categories/facet.numpunct/locale.numpunct/types.pass.cpp
test/std/localization/locales/locale.global.templates/use_facet.pass.cpp
When retrieving facets, the references are unused.
test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_long.pass.cpp
test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_unsigned_long.pass.cpp
"std::ios_base::iostate err = ios.goodbit;" was completely unused here.
test/std/localization/locale.categories/category.time/locale.time.get/time_base.pass.cpp
test/std/numerics/c.math/ctgmath.pass.cpp
test/std/numerics/rand/rand.device/entropy.pass.cpp
test/std/numerics/rand/rand.device/eval.pass.cpp
test/std/strings/basic.string/string.modifiers/string_copy/copy.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char16_t/eof.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char32_t/eof.pass.cpp
test/std/thread/futures/futures.promise/dtor.pass.cpp
test/std/thread/futures/futures.task/futures.task.members/dtor.pass.cpp
test/std/thread/thread.condition/thread.condition.condvar/wait_for_pred.pass.cpp
These variables are verifying types but are otherwise unused.
test/std/strings/basic.string/string.capacity/reserve.pass.cpp
old_cap was unused (it's unclear to me whether it was intended to be used).
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char/eq.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char16_t/eq.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char16_t/lt.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char32_t/eq.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char32_t/lt.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.wchar.t/eq.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.wchar.t/lt.pass.cpp
These tests contained unused characters.
llvm-svn: 286847
The end pointer should point to one past the end of the newly allocated
buffer.
rdar://problem/24265174
Differential Revision: http://reviews.llvm.org/D20334
llvm-svn: 274132
Summary:
GLIBC recently removed the incorrect `int isinf(double)` and `int isnan(double)` overloads in C++11 and greater. This causes previously `XFAIL: linux` tests to start passing.
Since there is no longer a way to 'XFAIL' the tests I choose to simply tolerate this bug.
See https://sourceware.org/bugzilla/show_bug.cgi?id=19439
Reviewers: rsmith, mclow.lists, EricWF
Subscribers: jroelofs, cfe-commits
Differential Revision: http://reviews.llvm.org/D19835
llvm-svn: 271060
