When the locale is not some UTF-8 these tests fail.
(different results for python2 linked gdbs vs. python3
but same issue)
Setting the locale just for the test works around this.
By default Ubuntu comes with just C.UTF-8. I've chosen
to use en_US.UTF-8 instead given that my Mac doesn't have
the former and there's a slim chance this test might run there.
This also enables the u16string tests which are now passing.
Reviewed By: #libc, ldionne, saugustine
Differential Revision: https://reviews.llvm.org/D111138
The unique (ha!) thing about this range type is that it's move-only.
Its contiguity is unsurprising (most of our test ranges are contiguous).
Discussed in D111231 but committed separately for clarity.
If you have a `begin() const` member, you don't need a `begin()` member
unless you want it to do something different (e.g. have a different return
type). So in general, //view// types don't need `begin()` non-const members.
Also, static_assert some things about the types in "types.h", so that we
don't accidentally break those properties under refactoring.
Differential Revision: https://reviews.llvm.org/D111231
Reduce code duplication by sharing most of the test suite setup across
the different from-scratch configs.
Differential Revision: https://reviews.llvm.org/D111196
Implement P1391 (https://wg21.link/p1391) which allows
`std::string_view` to be constructible from any contiguous range of
characters.
Note that a different paper (http://wg21.link/P1989) handles the generic
range constructor for `std::string_view`.
Reviewed By: ldionne, Quuxplusone, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D110718
This is less brittle than hand-picking the substitutions that we
pass to the test, since a config could theorically use non-base
substitutions as well (such as defining %{flags} in terms of another
substitution like %{include}).
Also, print the decoded substitutions, which makes it much easier
to debug the test when it fails.
Differential Revision: https://reviews.llvm.org/D111179
Some tests repeat the definition of `DELETE_FUNCTION` macro locally.
However, it's not even requred to guard against in the C++03 case since
Clang supports `= delete;` in C++03 mode. A warning is issued but
`libc++` tests run with `-Wno-c++11-extensions`, so this isn't an issue.
Since we don't support other compilers in C++03 mode, `= delete;` is
always available for use. As such, inline all calls of `DELETE_FUNCTION`
to use `= delete;`.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D111148
This was missed in ec574f5da4. TIME_UTC
is a define that goes along with timespec_get. The testcase that it is
moved to is only run for >= C++17, so the surrounding ifdef guard
can be dropped.
Differential Revision: https://reviews.llvm.org/D110988
The existing tests for transform_view::iterator weren't quite right,
and can be simplified now that we have more of C++20 available to us.
Having done that, let's use the same pattern for iota_view::iterator
as well.
Differential Revision: https://reviews.llvm.org/D110774
This adds the width estimation functions to the std-format-spec.
Implements parts of:
- P0645 Text Formatting
- P1868 width: clarifying units of width and precision in std::format
Reviewed By: #libc, ldionne, vitaut
Differential Revision: https://reviews.llvm.org/D103413
Even if these comments have a benefit in .h files (for editors that
care about language but can't be configured to treat .h as C++ code),
they certainly have no benefit for files with the .cpp extension.
Discussed in D110794.
Even if these comments have a benefit in .h files (for editors that
care about language but can't be configured to treat .h as C++ code),
they certainly have no benefit for files with the .cpp extension.
Discussed in D110794.
Apple's libc++ has a few differences with the LLVM libc++, and it is
necessary to use a custom configuration file to test it properly.
Differential Revision: https://reviews.llvm.org/D110777
To reduce confusion, this commit makes sure that the name of the testing
configurations match the convention used for the stdlib= Lit parameter,
since those effectively correspond to each other.
Vendors take libc++ and ship it in various ways. Some vendors might
ship it differently from what upstream LLVM does, i.e. the install
location might be different, some ABI properties might differ, etc.
In the past few years, I've come across several instances where
having a place to test some of these properties would have been
incredibly useful. I also just got bitten by the lack of tests
of that kind, so I'm adding some now.
The tests added by this commit for Apple platforms have numerous
TODOs that capture discrepancies between the upstream LLVM CMake
and the slightly-modified build we perform internally to produce
Apple's system libc++. In the future, the goal would be to upstream
all those differences so that it's possible to build a faithful
Apple system libc++ with the upstream LLVM sources only.
But this isn't only useful for Apple - this lays out the path for
any vendor being able to add their own checks (either upstream or
downstream) to libc++.
Differential Revision: https://reviews.llvm.org/D110736
Some of these were previously half-implemented in "ordering.h";
now they're all implemented, and tested.
Note that `constexpr` functions are implicitly `inline`, so the
standard wording omits `inline` on these; but Louis and I agree
that that's surprising and it's better to be explicit about it.
Differential Revision: https://reviews.llvm.org/D110515
Instead of using a base class to store the members and the optional
size, use [[no_unique_address]] to achieve the same thing without
needing a base class.
Also, as a fly-by:
- Change subrange from struct to class (per the standard)
- Improve the diagnostic for when one doesn't provide a size to the ctor of a sized subrange
- Replace this->member by just member since it's not in a dependent base anymore
This change would be an ABI break due to [[no_unique_address]], but we
haven't shipped ranges anywhere yet, so this shouldn't affect anyone.
Differential Revision: https://reviews.llvm.org/D110370
Before this patch, we had features named 'libc++', 'libstdc++' and
'msvc' to describe the three implementations that use our test suite.
This patch renames them to 'stdlib=libc++', 'stdlib=libstdc++', etc
to avoid confusion between MSVC's STL and the MSVC compiler (or Clang
in MSVC mode).
Furthermore, this prepares the terrain for adding support for additional
"implementations" to the test suite. Basically, I'd like to be able to
treat Apple's libc++ differently from LLVM's libc++ for the purpose of
testing, because those effectively behave in different ways in some aspects.
In reaction to the issues raised by Richard in https://llvm.org/D109066,
this commit does not apply P1951 as a DR in previous standard modes,
since it breaks valid code.
I do believe it should be applied as a DR, however ideally we'd get some
sort of statement from the Committee to this effect (and all implementations
would behave consistently). In the meantime, only implement P1951 starting
with C++23 -- we can always come back and apply it as a DR if that's what
the Committee says.
Differential Revision: https://reviews.llvm.org/D110347
I found this after upgrading from Ubuntu bionic (gdb 8.1.1) to
Focal (gdb 9.2). (where this test fails, but that's for a
different patch)
9.2 allows you to set breakpoint commands from
Python, which was added in 8.3.
(bintutils a913fffbdee21fdd50e8de0596358be425775678
"Allow breakpoint commands to be set from Python")
The reason this test never failed before was because it did so
silently. "source <python file>" doesn't fail even if that script
raises an Exception.
To fix this extend the gdb lit feature to check that:
* gdb exists
* has Python support
* allows you to set breakpoint commands
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D110334
Implements parts of P1614, including synth-three-way and three way comparison for std::pair.
Reviewed By: #libc, Quuxplusone, Mordante
Differential Revision: https://reviews.llvm.org/D107721
Instead of overloading `__to_address`, let's specialize `pointer_traits`.
Function overloads need to be in scope at the point where they're called,
whereas template specializations do not. (User code can provide pointer_traits
specializations to be used by already-included library code, so obviously
`__wrap_iter` can do the same.)
`pointer_traits<__wrap_iter<It>>` cannot provide `pointer_to`, because
you generally cannot create a `__wrap_iter` without also knowing the
identity of the container into which you're trying to create an iterator.
I believe this is OK; contiguous iterators are required to provide
`to_address` but *not* necessarily `pointer_to`.
Differential Revision: https://reviews.llvm.org/D110198
LWG 2447 is marked as `Complete`, but there is no `static_assert` to
reject volatile types in `std::allocator`. See the discussion at
https://reviews.llvm.org/D108856.
Add `static_assert` in `std::allocator` to disallow volatile types. Since this
is an implementation choice, mark the binding test as `libc++` only.
Remove tests that use containers backed by `std::allocator` that test
the container when used with a volatile type.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D109056
Two tests in span.cons/deduct.pass.cpp accidentally check whether the
iterator range from member begin and member end are equivalent to the
ones from free begin and free end. This is obviously true and not
intended. Correct the intent by comparing the size/data from the span
with the source input.
While in the neighborhood, add test for const int arr[N], remove extraneous
type aliases, unused <type_traits> header, and the
disable_missing_braces_warning.h include.
Reviewed By: Quuxplusone, ldionne, #libc
Differential Revision: https://reviews.llvm.org/D109668
Neither the current C++2b draft, nor any revision of [p1135],
nor libstdc++, claims that `counting_semaphore` should be
default-constructible. I think this was just a copy-paste issue
somehow.
Also, `explicit` was missing from the constructor.
Also, `constexpr` remains missing; but that's probably more of a
technical limitation, since apparently there are some platforms
where we don't (can't??) use the atomic implementation and
have to rely on pthreads, which obviously isn't constexpr.
Differential Revision: https://reviews.llvm.org/D110042
This implements the generic std.format.spec framework for all types.
The Unicode support will be added in a separate patch.
Implements parts of:
- P0645 Text Formatting
Completes:
- LWG-3242 std::format: missing rules for arg-id in width and precision
- P1892 Extended locale-specific presentation specifiers for std::format
Reviewed By: #libc, ldionne, vitaut
Differential Revision: https://reviews.llvm.org/D103368
- Simplify the structure of the new tests.
- Test const containers as well as non-const containers,
since it's easy to do so.
- Remove redundant enable-iffing of helper structs' member functions.
(They're not instantiated unless they're called, and who would call them?)
- Fix indentation and use more consistent SFINAE method in <unordered_map>.
- Add _LIBCPP_INLINE_VISIBILITY on some swap functions.
Differential Revision: https://reviews.llvm.org/D109011
Now that __builtin_is_constant_evaluated() is present on all supported
compilers, we can use it to skip the UB-inducing assert in cases where
the computation might be happening at constexpr time.
Differential Revision: https://reviews.llvm.org/D101674
The majority of the changes here are whitespace.
Also simplify `ThrowingIterator`'s bookkeeping (NFC).
Also move some free operators into hidden friends, for sanity's sake.
Also `=delete` some more comma operators.
Also use `constexpr` in C++20 instead of `TEST_CONSTEXPR_CXX14`.
Differential Revision: https://reviews.llvm.org/D103341
Summary:
AIX have 2 byte wchar in 32 bit mode and 4 byte wchar in 64 bit mode.
This patch add more missing short wchar handling under the existing _LIBCPP_SHORT_WCHAR macro.
Marked test case ctor_move.pass.cpp as XFAIL for 32-bit mode on AIX because UTF-8 constants used cannot be converted to 2-byte wchar (by xingxue).
Authored by: jasonliu
Reviewed by: ldionne, zibi, SeanP, libc++
Differential Revision: https://reviews.llvm.org/D100777
Detected by evil-izing the widely used `MoveOnly` testing type.
I had to patch some tests that were themselves using its comma operator,
but I think that's a worthwhile cost in order to catch more places
in our headers that needed comma-proofing.
The trick here is that even `++ptr, SomeClass()` can find a comma operator
by ADL, if `ptr` is of type `Evil*`. (A comma between two operands
of non-class-or-enum type is always treated as the built-in
comma, without ADL. But if either operand is class-or-enum, then
ADL happens for _both_ operands' types.)
Differential Revision: https://reviews.llvm.org/D109414
Use the same codepaths as for MSVC. Mingw-w64 does have the _mktemp_s
function; on Vista and newer, msvcrt.dll does contain the function,
which ends up called. (Same thing in the UCRT.) In older versions of
msvcrt.dll (older than what libc++ supports), mingw-w64 provides a
fallback implementation.
This effectively reverts 23323e25f8 (and
d07e5c23b4). That commit tried to fix
unspecified MinGW build breakage.
This reduces the risk of temp name collisions between processes (when
running multiple tests in parallel); the path returned by
GetTempFileName can easily collide with other similar paths.
(_mktemp_s on the other hand tries to avoid such clashes by using
the process id as part of the uniqueness seed.)
This avoids stray random failures in fstreams tests in mingw configurations.
Differential Revision: https://reviews.llvm.org/D98526
There were basically two bugs here:
When C++20 `to_address` is called on `int arr[10]`, then `const _Ptr&` becomes
a reference to a const array, and then we dispatch to `__to_address<const int(&)[10]>`,
which, oops, gives us a `const int*` result instead of an `int*` result.
Solution: We need to provide the two standard-specified overloads of
`std::to_address` in exactly the same way that we provide two overloads
of `__to_address`.
When `__to_address` is called on a pointer type, `__to_address(const _Ptr&)`
is disabled so we successfully avoid trying to instantiate pointer_traits of
that pointer type. But when it's called on an array type, it's not disabled
for array types, so we go ahead and instantiate pointer_traits<int[10]>,
which goes boom. Solution: We need to disable `__to_address(const _Ptr&)`
for both pointer and array types. Also disable it for function types,
so that they get the nice error message; and put a test on it.
Differential Revision: https://reviews.llvm.org/D109331
Add tests showing `span` is trivially_destructible and nothrow_destructible.
Note that we do not need to explicitly default the destructor in `span`.
Reviewed By: ldionne, Mordante, #libc
Differential Revision: https://reviews.llvm.org/D109286
Implementation of `three_way_comparable` and `three_way_comparable_with` concepts from <compare> header.
Please note that I have temporarily removed `<compare>` header from `<utility>` due to cyclic dependency that prevents using `<concepts>` header in `<compare>` one.
I tried to quickly resolve those issues including applying suggestions from @cjdb and dive deeper by myself but the problem seems more complicated that we thought initially.
I am in progress to prepare the patch with resolving this cyclic dependency between headers but for now I decided to put all that I have to the review to unblock people that depend on that functionality. At first glance the patch with resolving cyclic dependency is not so small (unless I find the way to make it smaller and cleaner) so I don't want to mix everything to one review.
Reviewed By: ldionne, cjdb, #libc, Quuxplusone
Differential Revision: https://reviews.llvm.org/D103478
This implements the initial version of the `std::formatter` class and its specializations. It also implements the following formatting functions:
- `format`
- `vformat`
- `format_to`
- `vformat_to`
- `format_to_n`
- `formatted_size`
All functions have a `char` and `wchar_t` version. Parsing the format-spec and
using the parsed format-spec hasn't been implemented. The code isn't optimized,
neither for speed, nor for size.
The goal is to have the rudimentary basics working, which can be used as a
basis to improve upon. The formatters used in this commit are simple stubs that
will be replaced by real formatters in later commits.
The formatters that are slated to be replaced in this patch series don't have
an availability macro to avoid merge conflicts.
Note the formatter for `bool` uses `0` and `1` instead of "false" and
"true". This will be fixed when the stub is replaced with a real
formatter.
Implements parts of:
- P0645 Text Formatting
Completes:
- LWG3539 format_to must not copy models of output_iterator<const charT&>
Reviewed By: ldionne, #libc, vitaut
Differential Revision: https://reviews.llvm.org/D96664
Those constructors are very easy to misuse -- one could easily think that
the size passed to the constructor is the size of the range to exhibit
from the subrange. Instead, it's a size hint and it's UB to get it wrong.
Hence, when it's cheap to compute the real size of the range, it's cheap
to make sure that the user didn't get it wrong.
Differential Revision: https://reviews.llvm.org/D108827
It appears when testing LLVM 13 on Power, we run into failures with the
`libcxx/test/libcxx/gdb/gdb_pretty_printer_test.sh.cpp` test case optimizing
values out.
Despite some the functions in the test already being marked with optnone,
adding the `MarkAsLive()` calls inside of the pretty printer comparison functions
resolves the issues of the values being optimized out.
This patch aims to address https://llvm.org/PR51675.
Differential Revision: https://reviews.llvm.org/D109204
The `insert_iterator::iter` member is defined as `Container::iterator` but
the standard requires `iter` to be defined in terms of `ranges::iterator_t` as
of C++20. So, if in C++20 or later, define the `iter` member as
`ranges::iterator_t`.
Original patch by Joe Loser!
Differential Revision: https://reviews.llvm.org/D108575
This implements the struct `__format_arg_store` and its dependencies:
* the class basic_format_arg,
* the class basic_format_args,
* the class basic_format_context,
* the function make_format_args,
* the function wmake_format_args,
* the function visit_format_arg,
* several Standard required typedefs.
The following parts will be implemented in a later patch:
* the child class `basic_format_arg::handle`,
* the function `basic_format_arg::basic_format_arg(const T* p)`.
The following extension has been implemented:
* the class basic_format_arg supports `__[u]int128_t` on platform where libc++ supports 128 bit integrals.
Implements parts of:
* P0645 Text Formatting
Completes:
* LWG3371 visit_format_arg and make_format_args are not hidden friends
* LWG3542 basic_format_arg mishandles basic_string_view with custom traits
Note https://mordante.github.io/blog/2021/06/05/format.html gives a bit more information about the goals and non-goals of this initial patch series.
Reviewed By: #libc, ldionne, vitaut
Differential Revision: https://reviews.llvm.org/D103357
`contiguous_iterator` requires the iterator type passed is either a
pointer type or that the element type of the iterator is a complete
object type. These constraints are not part of the current wording in
defining the `contiguous_iterator` concept - adjust the concept to
reflect this.
Inspired from discussion at https://reviews.llvm.org/D108645.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D108855
This move the helper types `chars_format`, `to_chars_result` and
`from_chars_result` to a separate header. The first two are needed for
D70631 the third for consistency.
The header `__charconv/ryu.h` uses these types and it can't depend on the
types in `<charconv>` in a modular build. Moving them to the ryu header
would be an odd place and doesn't work since the header is included in the
middle of `<charconv>`.
Reviewed By: #libc, ldionne, Quuxplusone
Differential Revision: https://reviews.llvm.org/D108927
This fixes -isystem/-L/-Wl,-rpath paths when -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=on
is used (https://reviews.llvm.org/D107799#2969650).
* `-isystem path/to/build/generic-cxx17/include/c++/v1`. `build/generic-cxx17/include/x86_64-unknown-linux-gnu/c++/v1 (__config_site)` is missing.
* `-L path/to/build/generic-cxx17/lib`. Should be `build/generic-cxx17/lib/x86_64-unknown-linux-gnu` instead
Reviewed By: ldionne, phosek, #libc
Differential Revision: https://reviews.llvm.org/D108836
- Rename test files to follow conventions better
- Split constructor tests that were in a single file
- Add missing tests for take_view and transform_view's default constructors
- Add missing tests for transform_view's view/function constructor
- Fix include guards
- Mark some tests as being specific to libc++
Differential Revision: https://reviews.llvm.org/D108829
We don't use double underscores for private header names when they are
in a subdirectory with double underscores already.
Differential Revision: https://reviews.llvm.org/D108820
This patch implements the underlying mechanism for range adaptors. It
does so based on http://wg21.link/p2387, even though that paper hasn't
been adopted yet. In the future, if p2387 is adopted, it would suffice
to rename `__bind_back` to `std::bind_back` and `__range_adaptor_closure`
to `std::range_adaptor_closure` to implement that paper by the spec.
Differential Revision: https://reviews.llvm.org/D107098
This patch XFAILs the `align.pass.cpp` for PowerPC (LE).
It appears that this test will fail on Power for the `LLIArr2` and `Padding` structs within the test,
as the `assert` for `alignof(AtomicImpl) >= sizeof(AtomicImpl)` will be false. In this case, these structs
presumably should not be lock-free, so we currently XFAIL this for now.
The failure was discovered after D97913 was committed. It looks like `alignof(AtomicImpl) < sizeof(AtomicImpl)`,
even prior to this commit, but this test began running on Power after D97913, whereas we were
not running `align.pass.cpp` before.
This patch addresses https://bugs.llvm.org/show_bug.cgi?id=51548 by temporarily XFAILing the test
in order to investigate it further.
Differential Revision: https://reviews.llvm.org/D108668
We don't support any compiler that doesn't support C++14 constexpr when
compiling in C++14 mode anymore, so we can just assume that we have C++14
extended constexpr when compiling in C++14 mode. This allows us to remove
some workarounds for older compilers.
Differential Revision: https://reviews.llvm.org/D108638
Based on https://github.com/NuxiNL/cloudlibc, it appears that the CloudABI
project has been abandoned. This patch removes a bunch of CloudABI specific
logic that had been added to support that platform.
Note that some knobs like LIBCXX_ENABLE_STDIN and LIBCXX_ENABLE_STDOUT
coud be useful in their own right, however those are currently broken.
If we want to re-add such knobs in the future, we can do it like we've
done it for localization & friends so that we can officially support
that configuration.
Differential Revision: https://reviews.llvm.org/D108637
The aim of this patch is to remove the assumption that the character 'a' is always 97. In turn, this patch explicitly uses the character values to account for the EBCDIC 'a' that is not 97.
Differential Revision: https://reviews.llvm.org/D108321
The test case is not ran unless libcxx is used, and a macro
may be undefined. This patch checks for the definition of the
macro before using it.
Fixes http://llvm.org/PR51430
Differential Revision: https://reviews.llvm.org/D108352
This allows testing the rest of those headers on most platforms, instead
of XFAILing the whole test just because of a few functions.
As a fly-by fix, remove std/utilities/time/date.time/ctime.pass.cpp,
which was a duplicate of std/language.support/support.runtime/ctime.pass.cpp.
Differential Revision: https://reviews.llvm.org/D108295
The `get` half of this machinery was already implemented, but the `tuple_size`
and `tuple_element` parts were hiding in [ranges.syn] and therefore missed.
Differential Revision: https://reviews.llvm.org/D108054
All supported compilers have supported deduction guides in C++17 for a
while, so this isn't necessary anymore.
Differential Revision: https://reviews.llvm.org/D108213
The test precision_type.pass.cpp was a duplicate of precision.pass.cpp,
so it is removed. atomic_flag_test.pass.cpp was a duplicate of
atomic_flag_test_and_set.pass.cpp, so instead I wrote a proper
test for it. Those duplicate tests were detected with
find libcxx ! -empty -type f -exec md5sum {} + | sort | uniq -w32 -dD
Instead of trying to sniff out what features are supported by the
library being tested, the way we normally handle these things is with
Lit annotations. This should not be treated differently.
Differential Revision: https://reviews.llvm.org/D108209
As explained in http://eel.is/c++draft/range.nonprop.cache#note-1, we
should allow copy and move elision to happen when calling emplace_deref
in non-propagating-cache. Before this change, the only way to emplace
into the non-propagating-cache was to call `__set(*it)`, which materialized
`*it` when binding it to the reference argument of `__set` and disabled
move elision.
As a fly-by change, this also renames `__set` to `__emplace` for consistency
and adds tests for it.
Differential Revision: https://reviews.llvm.org/D107932
Since we officially don't support several older compilers now, we can
drop a lot of the markup in the test suite. This helps keep the test
suite simple and makes sure that UNSUPPORTED annotations don't rot.
This is the first patch of a series that will remove annotations for
compilers that are now unsupported.
Differential Revision: https://reviews.llvm.org/D107787
This is a workaround until https://reviews.llvm.org/D81892 is merged
and the internal Lit shell stops conflating error output with normal
output. Without this, any program that writes to stderr will trip up
the programOutput function, because it will pick up the '# command stderr:'
string and think it's part of the command's stdout.
rdar://81056048
Differential Revision: https://reviews.llvm.org/D107912
All supported compilers implement __builtin_addressof. Even MSVC implements
addressof as a simple call to __builtin_addressof, so it would work if we
were to port libc++ to that compiler.
Differential Revision: https://reviews.llvm.org/D107905
efriedma noted that D104682 broke this test case, reduced from SPEC2006.
#include <istream>
bool a(std::istream a) {
return a.getline(0,0) == 0;
}
We can unbreak it by restoring the conversion to something-convertible-to-bool.
We chose `void*` in order to match libstdc++.
For more ancient history, see PR19460: https://bugs.llvm.org/show_bug.cgi?id=19460
Differential Revision: https://reviews.llvm.org/D107663
All supported compilers have implemented __has_unique_object_representations
for a while, so it's reasonable to remove the workaround.
Differential Revision: https://reviews.llvm.org/D107834
All supported compilers have been supporting __is_aggregate for a long
time now, so it's reasonable to remove this workaround.
Differential Revision: https://reviews.llvm.org/D107833
All supported compilers should support
_LIBCPP_HAS_NO_BUILTIN_IS_CONSTANT_EVALUATED so this can be removed.
Reviewed By: ldionne, #libc, Quuxplusone
Differential Revision: https://reviews.llvm.org/D107239
This one already had a proper explanation why it fails, which is due to
differences by design in MSVC mode. This isn't a fixme, so degrade the
annotation to a more permanent "XFAIL: msvc" instead.
Differential Revision: https://reviews.llvm.org/D107758
Such environments do have aligned allocation functions these days, but
the RTTI type name test needs to be adjusted for the MSVC C++ ABI.
Differential Revision: https://reviews.llvm.org/D107757
This allows waiving the right amount of asserts on Windows and zOS.
This should supersede D107124 and D105910.
Differential Revision: https://reviews.llvm.org/D107755
This patch fixes the constrains on the __perfect_forward constructor
and its call operators, which were incorrect. In particular, it makes
sure that we closely follow [func.require], which basically says that
we must deliver the bound arguments with the appropriate value category
or make the call ill-formed, but not silently fall back to using a
different value category.
As a fly-by, this patch also:
- Adds types __bind_front_t and __not_fn_t to make the result of
calling bind_front and not_fn more opaque, and improve diagnostics
for users.
- Adds a bunch of tests for bind_front and remove some that are now
redundant.
- Adds some missing _LIBCPP_HIDE_FROM_ABI annotations.
Immense thanks to @tcanens for raising awareness about this issue, and
providing help with the = delete bits.
Differential Revision: https://reviews.llvm.org/D107199
Also, improve tests for std::destroy and std::destroy_n so that they
check for array support.
These changes are part of http://wg21.link/p0896 (the One Ranges proposal).
Differential Revision: https://reviews.llvm.org/D106916
Summary:
Currently, if we pass in the same iterator for begin and end,
the long double version of do_get would throw a runtime error.
However, according to standard (https://eel.is/c++draft/locale.money.get#virtuals-1),
we should set the failbit and eofbit when no more characters are available.
Differential Revision: https://reviews.llvm.org/D100510
Implement the changes in all language modes.
LWG3506 "Missing allocator-extended constructors for priority_queue"
makes the following changes:
- New allocator-extended constructors for priority_queue.
- New deduction guides targeting those constructors.
LWG3522: "Missing requirement on InputIterator template parameter
for priority_queue constructors". The iterator parameter should be
constrained to actually be an iterator type. `priority_queue{1,2}`
should be SFINAE-friendly ill-formed.
Also, do a drive-by fix in the allocator-extended move constructor:
there's no need to do a `make_heap` after moving from `__q.c` into
our own `c`, because that container was already heapified when it
was part of `__q`. [priqueue.cons.alloc] actually specifies the
behavior and does *not* mention calling `make_heap`. I think this
was just a copy-paste thinko. It dates back to the initial import
of libc++.
Differential Revision: https://reviews.llvm.org/D106824
Differential Revision: https://reviews.llvm.org/D106827
This started breaking in the CI because we bumped the Clang version to 14,
which requires adjusting the markup in the test suite. I think it's actually
nice the we need to do that and that it doesn't happen automatically, since
it serves as a reminder that this is broken in Clang.
Adds a new CMake option to disable the usage of incomplete headers.
These incomplete headers are not guaranteed to be ABI stable. This
option is intended to be used by vendors so they can avoid their users
from code that's not ready for production usage.
The option is enabled by default.
Differential Revision: https://reviews.llvm.org/D106763
See LWG reflector thread of 2021-07-23 titled
'Question on ranges::advance and "past-the-sentinel iterators"'.
Test case heavily based on one graciously provided by Casey Carter.
Differential Revision: https://reviews.llvm.org/D106735
Move the tests to libcxx so they no longer need `REQUIRES: libc++`.
Verify tests don't need `REQUIRES: libc++`.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D106673
This started as fixing a typo in a ADDITIONAL_COMPILE_FLAGS directive
which turned out to uncover a few places where we warned about signedness
changes.
As a fly-by fix, this updates the various __advance overloads
for style consistency.
Differential Revision: https://reviews.llvm.org/D106372
`__function_like` wasn't being exported, so certain properties of the
`ranges` functions weren't being propagated in modules land.
Differential Revision: https://reviews.llvm.org/D105078
libc++ has started splicing standard library headers into much more
fine-grained content for maintainability. It's very likely that outdated
and naive tooling (some of which is outside of LLVM's scope) will
suggest users include things such as `<__algorithm/find.h>` instead of
`<algorithm>`, and Hyrum's law suggests that users will eventually begin
to rely on this without the help of tooling. As such, this commit
intends to protect users from themselves, by making it a hard error for
anyone outside of the standard library to include libc++ detail headers.
This is the first of four patches. Patch #2 will solve the problem for
pre-processor `#include`s; patches #3 and #4 will solve the problem for
`<__tree>` and `<__hash_table>` (since I've never touched the test cases
that are failing for these two, I want to split them out into their own
commits to be extra careful). Patch #5 will concern itself with
`<__threading_support>`, which intersects with libcxxabi (which I know
even less about).
Differential Revision: https://reviews.llvm.org/D105932
The checks within the libc++experimental memory_resource class uses this
limit:
_MaxAlign = _LIBCPP_ALIGNOF(max_align_t);
Therefore, only use max_align_t for this limit instead of using
`__STDCPP_DEFAULT_NEW_ALIGNMENT__` if available.
Differential Revision: https://reviews.llvm.org/D105905
* <__algorithm/iter_swap.h>
* <__algorithm/swap_ranges.h>
* <__functional/is_transparent.h>
* <__memory/uses_allocator.h>
* <__ranges/drop_view.h>
* <__ranges/transform_view.h>
* <shared_mutex>
* <span>
Also updates header inclusions that were affected.
**NOTE:** This is a proper subset of D105932. Since the content has
already been LGTM'd, I intend to merge this patch without review,
pending green CI. I decided it would be better to move these changes
into their own commit since the former patch has undergone further
changes and will need yet another light review. In the event any of
that gets rolled back (for whatever reason), the changes in this patch
won't be affected.
Differential Revision: https://reviews.llvm.org/D106040
Instead of using TARGET_TRIPLE, which is always set to LLVM_DEFAULT_TARGET_TRIPLE,
use that variable directly to populate the various XXXX_TARGET_TRIPLE
variables in the runtimes.
This re-applies 77396bbc98 and 5099e01568, which were reverted in
850b57c5fb because they broke the build.
Differential Revision: https://reviews.llvm.org/D106009
This configuration is interesting because GCC has a different level of
strictness for some C++ rules. In particular, it implements the older
standards more stringently than Clang, which can help find places where
we are non-conforming (especially in the test suite).
Differential Revision: https://reviews.llvm.org/D105936
The XFAIL comments about VCRuntime not providing aligned operator new
are outdated; these days VCRuntime does provide them.
However, the tests used to fail on Windows, as the pointers allocated
with an aligned operator new (which is implemented with _aligned_malloc
on Windows) can't be freed using std::free() on Windows (but they need
to be freed with the corresponding function _aligned_free instead).
Instead override the aligned operator new to return a dummy suitably
aligned pointer instead, like other tests that override aligned operator
new.
Also override `operator delete[]` instead of plain `operator delete`
in the array testcase; the fallback from `operator delete[]` to
user defined `operator delete` doesn't work in all DLL build
configurations on Windows.
Also expand the TEST_NOEXCEPT macros, as these tests only are built
in C++17 mode.
By providing the aligned operator new within the tests, this also makes
these test cases pass when testing back deployment on macOS 10.9.
Differential Revision: https://reviews.llvm.org/D105962
David Spickett