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
We just had a case where a build bot stalled in an infinite loop during
testing, and the whole pipeline got stuck. To avoid that from happening
in the future, use a timeout on BuildKite jobs.
Differential Revision: https://reviews.llvm.org/D107765
Shorty before branching LLVM 13 a new CMake option was added. This
option `LIBCXX_ENABLE_INCOMPLETE_FEATURES` lacks the contributor
documentation. This patch rectifies that issue.
Differential Revision: https://reviews.llvm.org/D107596
Switching `__builtin_clzll` to `__libcpp_clz` should work on all
platforms and no longer require MSVC specific code.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D107709
@tcanens pointed out the current behavior of the macro breaks the usage
pattern described in http://wg21.link/SD6
```
# if __has_include(<optional>)
# include <optional>
# if __cpp_lib_optional >= 201606
# define have_optional 1
# endif
```
To support this usage pattern the hard errror is removed. Instead the
header includes nothing but the `<version>` header.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D107134
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.
The error message for disabled filesystem and locale support is now done
in the same fashion as ranges and format in D106763.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D106935
This was missed in 08c766a731
and caused test failures in the buildkite bots:
libcpp_version.pass.cpp:22:1:
error: static_assert failed due to requirement '14000 == libcpp_version'
"_LIBCPP_VERSION doesn't match __libcpp_version
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
Building the libraries with -fPIC ensures that we can link an executable
against the static libraries with -fPIE. Furthermore, there is apparently
basically no downside to building the libraries with position independent
code, since modern toolchains are sufficiently clever.
This commit enforces that we always build the runtime libraries with -fPIC.
This is another take on D104327, which instead makes the decision of whether
to build with -fPIC or not to the build script that drives the runtimes'
build.
Fixes http://llvm.org/PR43604.
Differential Revision: https://reviews.llvm.org/D104328
Feedback requested in D106735 applied in Diff 3 seem to have
reverted in Diff 4. This patch fixes that up.
Differential Revision: https://reviews.llvm.org/D106829
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
Even though the standalone build is deprecated, some people are still
relying on it (including libc++ itself for some configurations). Setting
the target triple will ensure that the build and the test suite behaves
consistently in the standalone and normal builds.
Differential Revision: https://reviews.llvm.org/D106800
The Generated output CI job only tests for modified files. This job
should also fail the generated output contains new files.
It would be possible to test modified and untracked files in one
execution of `git ls-files`. However the diff is stored as an artifact
so the execution of `git diff` would still be required.
Discussion: Would it be better to do `git ls-files -om` and remove the
excution of
`! grep -q '^--- a' ${BUILD_DIR}/generated_output.patch || false` ?
(Obviously then the name `generated_output.untracked` should change to
something like `generated_output.status`)
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D106534
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
Updates the status pages with the LWG issues accepted in the Standard
during the June 2021 plenary session. The LWG papers for this meeting
have been added in D105103.
Differential Revision: https://reviews.llvm.org/D106529
`__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
This is a spin-off from D79555 review, that with this patch will be able to use `__libcpp_copysign` instead of adhoc `__copysign_constexpr` helper.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D106364
This replaces _LIBCPP_INLINE_VISIBILITY with _LIBCPP_HIDE_FROM_ABI. It's
not intended to do for other parts of libc++. This change makes it easy
to search and replace all occurrences of the patches in review.
We've been forgetting to add those to most of the <ranges> review.
To avoid forgetting in the future, I added an item in the pre-commit
checklist.
Differential Revision: https://reviews.llvm.org/D106287
The new testing configuration did not turn off #pragma system_header,
which means we were not seeing warnings in system headers.
Differential Revision: https://reviews.llvm.org/D106187
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
When a target triple is specified in CMake via XXX_TARGET_TRIPLE, we tried
passing the --target=<...> flag to the compiler. However, not all compilers
support that flag (e.g. GCC, which is not a cross-compiler). As a result,
setting e.g. LIBCXX_TARGET_TRIPLE=<host-triple> would end up trying to
pass --target=<host-triple> to GCC, which breaks everything because the
flag isn't even supported.
This commit only adds `--target=<...>` & friends to the flags if it is
supported by the compiler.
One could argue that it's confusing to pass LIBCXX_TARGET_TRIPLE=<...>
and have it be ignored. That's correct, and one possibility would be
to assert that the requested triple is the same as the host triple when
we know the compiler is unable to cross-compile. However, note that this
is a pre-existing issue (setting the TARGET_TRIPLE variable never had an
influence on the flags passed to the compiler), and also fixing that is
starting to look like reimplementing a lot of CMake logic that is already
handled with CMAKE_CXX_COMPILER_TARGET.
Differential Revision: https://reviews.llvm.org/D106082
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
The feature was always defined, which means that the two test cases
guarded by it were never run.
Differential Revision: https://reviews.llvm.org/D106062
As we automate more and more things in the library, it becomes useful for
contributors to have a single target for running all the automation as
part of their workflow. This commit adds a new `libcxx-generate-files`
target that should re-generate all the auto-generated files in the library.
As a fly-by, I also revamped the documentation on Contributing to account
for this new target and present it as a bullet list of things to check
before committing. I also added a few things that are often overlooked
to that list, such as updating the synopsis and the status files.
Differential Revision: https://reviews.llvm.org/D106067
add_lit_testsuite() takes Lit parameters passed to it and adds them
to the parameters used globally when running all test suites. That
means that a target like `check-all`, which ends up calling Lit on
the whole monorepo, will see the test parameters for all the individual
project's test suites.
So, for example, it would see `--param std=c++03` (from libc++abi), and
`--param std=c++03` (from libc++), and `--param whatever` (from another
project being tested at the same time). While always unclean, that works
when the parameters all agree. However, if the parameters share the same
name but have different values, only one of those two values will be used
and it will be incredibly confusing to understand why one of the test
suites is being run with the incorrect parameter value.
For that reason, this commit moves away from using add_lit_testsuite()'s
PARAM functionality, and serializes the parameter values for the runtimes
in the generated config.py file instead, which is local to the specific
test suite.
Differential Revision: https://reviews.llvm.org/D105991
It turns out that D105040 broke `std::rel_ops`; we actually do need
both a one-template-parameter and a two-template-parameter version of
all the comparison operators, because if we have only the heterogeneous
two-parameter version, then `x > x` is ambiguous:
template<class T, class U> int f(S<T>, S<U>) { return 1; }
template<class T> int f(T, T) { return 2; } // rel_ops
S<int> s; f(s,s); // ambiguous between #1 and #2
Adding the one-template-parameter version fixes the ambiguity:
template<class T, class U> int f(S<T>, S<U>) { return 1; }
template<class T> int f(T, T) { return 2; } // rel_ops
template<class T> int f(S<T>, S<T>) { return 3; }
S<int> s; f(s,s); // #3 beats both #1 and #2
We have the same problem with `reverse_iterator` as with `__wrap_iter`.
But so do libstdc++ and Microsoft, so we're not going to worry about it.
Differential Revision: https://reviews.llvm.org/D105894
This commit reverts 5099e01568 and 77396bbc98, which broke the build
in various ways. I'm reverting until I can investigate, since that
change appears to be way more subtle than it seemed.
On Windows, structs with a destructor are always returned indirectly;
add this to the list of known exceptions in the test where the class
isn't returned in registers as expected.
Differential Revision: https://reviews.llvm.org/D105906
This is a second attempt at D101497, which landed as
9a9bc76c0e but had to be reverted in
8cf7ddbdd4.
This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is
empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to
"/bin" not "bin" as intended and as was originally.
One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty,
defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach.
But, I think it is more ergonomic to allow those project-specific paths
to be relative the global ones. Also, making install paths absolute by
default inhibits the proper behavior of functions like
`GNUInstallDirs_get_absolute_install_dir` which make relative install
paths absolute in a more complicated way.
Given all this, I will define a function like the one asked for in
https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a
similar use-case).
---
Original message:
Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for
complier-rt, just use it to define variables for the subdirs which
themselves are used.
This preserves compatibility, but later on we might consider getting rid
of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the
subdir variables directly.
---
There was a seaming bug where the (non-Apple) per-target libdir was
`${target}` not `lib/${target}`. I suspect that has to do with the docs
on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no
longer true, so I just went ahead and fixed it, allowing me to define
fewer and more sensible variables.
That last part should be the only behavior changes; everything else
should be a pure refactoring.
---
I added some documentation of these variables too. In particular, I
wanted to highlight the gotcha where `-DSomeCachePath=...` without the
`:PATH` will lead CMake to make the path absolute. See [1] for
discussion of the problem, and [2] for the brief official documentation
they added as a result.
[1]: https://cmake.org/pipermail/cmake/2015-March/060204.html
[2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options
In 38b2dec37e the problem was somewhat
misidentified and so `:STRING` was used, but `:PATH` is better as it
sets the correct type from the get-go.
---
D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands,
it should be feasible to follow both of these up with a simple patch for
compiler-rt analogous to the one for libcxx.
Reviewed By: phosek, #libc_abi, #libunwind
Differential Revision: https://reviews.llvm.org/D105765
std::exchange is only constexpr in C++20 and later. We were using it
in a constructor marked unconditionally constexpr, which caused issues
when building with -std=c++17.
The weird part is that the issue only showed up when building on the
arm64 macs, but that must be caused by the specific version of Clang
used on those. Since the code is clearly wrong and the fix is obvious,
I'm not going to investigate this further.
Make sure that the detached thread has started up before exiting
the process.
This is exactly the same fix as D105592, with the same pattern
being present in a different test case.
Differential Revision: https://reviews.llvm.org/D105736
This is what ffccf96e90 should have enabled, however the symlink
in the Docker image was not pointing to the right compiler, so we were
testing with Clang 12 instead of ToT.
For reasons unknown, the build is now using compilers
from /usr/bin instead of /usr/local/bin which is where
we have our clang-12 aliases placed.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D105704
This will allow us to use variant in common_iterator. We do this by introducing a new `__light_array` type that variant uses instead of `std::array`.
Differential Revision: https://reviews.llvm.org/D105597
It makes the most sense to test with Clang ToT by default since that's
exactly what we're trying to QA: that libc++ works with whatever compiler
we're going to release next.
The compiler support policy mentions that we support Clang 11 and 12, so
we should test those. We already test on Clang 12, but I'll add testers
for Clang 11 once the new Docker image is in use on all the builders.
This is the first of a few commits that update the CI to match the
recently officialized compiler support policy. I'm staging those
changes to try and keep the CI green at all times, accounting how
builders refresh their Docker image.
The format library uses `std::monostate`, but not a `std::variant`.
Moving `std::monostate` to its own header allows the format library to
reduce the amount of included code.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D105582
The unit tests test some implementation details. As @Quuxplusone pointed
out in D96664 this should only be tested when the tests use libc++. This
addresses the issue for code already in main.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D105568
Make sure that the detached thread has started up before exiting
the process.
If the detached thread hasn't started up at all, and the main thread
exits, global data structures in the process are torn down, which
then can cause crashes when the thread starts up late after required
mutexes have been destroyed. (In particular, the mutex used internally
in _Init_thread_header, which is used in the initialization of
__thread_local_data()::__p, can cause crashes if the main thread already
has finished and progressed far with destruction.)
Differential Revision: https://reviews.llvm.org/D105592
I'm not sure what that gains us, and it creates a problem when
trying to run the tests against libc++ with a custom install name
dir (e.g. /usr/lib), since the library that we link against (in
the build tree) will advertise itself as /usr/lib/libc++.dylib,
so we end up linking against the system dylib at runtime.
Differential Revision: https://reviews.llvm.org/D105499
This patch overhauls the documentation around building libc++
for vendors, and using libc++ for end-users. It also:
- Removes mention of the standalone build, which we've been trying to
get rid of for a long time.
- Removes mention of using a local ABI installation, which we don't do
and is documented as "not recommended".
- Removes mention of the separate libc++filesystem.a library, which isn't
relevant anymore since filesystem support is in the main library.
- Adds mention of the GDB pretty printers and how to use them.
This is necessary for from-scratch configurations to support the 32-bit
mode of the test suite.
Differential Revision: https://reviews.llvm.org/D105435
Now that Lit supports regular expressions inside XFAIL & friends, it is
much easier to write Lit annotations based on the triple.
Differential Revision: https://reviews.llvm.org/D104747
Summary:
If we are on c++03 mode for some reason, and __builtin_va_copy is
available, then use it instead of error out on not having va_copy
in 03 mode.
Reviewed by: ldionne
Differential Revision: https://reviews.llvm.org/D100336
This is required to run the tests under any configuration that uses
additional_features using a from-scratch config. That is the case of
e.g. the Debug mode (which uses LIBCXX-DEBUG-FIXME) and the tests on
Windows.
The various design docs have been moved to RST, and the linked blog post
does not apply anymore since libc++ is the default library used by Clang
on Apple platforms.
While we can debate on the value of passing by const value, there is no
arguing that it's confusing to do so in some circumstances, such as when
marking a pointer parameter as being const (did you mean a pointer-to-const?).
This commit fixes a few issues along those lines.
The __search helper function was once split into __functional for circular
dependency reasons, however this is not an issue anymore now that we have
finer grained headers.
Before this patch, Lit parameters that were set as a result of CMake
options were not made available to from-scratch configs. This patch
serializes those parameters into the generated lit config file so that
they are available to all configs.
Differential Revision: https://reviews.llvm.org/D105047
This patch is to fix 2 libcxx test cases, test cases assumed 'a' > 'A' which is not case in z/OS platform on ebcdic mode, modified test cases to compare between upper letters or lower letters, or digits so ordering will be true for all platform.
Differential Revision: https://reviews.llvm.org/D104748
With the STL containers, I didn't enable move operations in C++03 mode
because that would change the overload resolution for things that today
are copy operations. With iostreams, though, the copy operations aren't
present at all, and so I see no problem with enabling move operations
even in (Clang's greatly extended) C++03 mode.
Clang's C++03 mode does not support delegating constructors.
Differential Revision: https://reviews.llvm.org/D104310
In typeinfo there is a reinterpret_cast between a uintptr_t and size_t. These are two integer types and therefore a reinterpret_cast is not right for this situation. It looks like it may have been copied and pasted from above in the file. An implicit cast works in it's place.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D104814
Moves:
* `std::move`, `std::forward`, `std::declval`, and `std::swap` into
`__utility/${FUNCTION_NAME}`.
* `std::swap_ranges` and `std::iter_swap` into
`__algorithm/${FUNCTION_NAME}`
Differential Revision: https://reviews.llvm.org/D103734
Under the as-if rule, we can directly implement the array overload for
`std::swap`. By removing this circular dependency where `swap` is
implemented in terms of `swap_ranges` and `swap_ranges` is defined in
terms of `swap`, we can split them into their own headers. This will:
* limit the surface area in which Hyrum's law can bite us;
* force users to include the correct headers;
* make finding the definitions trivial (`swap` is a utility;
`swap_ranges` is an algorithm).
Differential Revision: https://reviews.llvm.org/D104760
Since we now have modules-enabled CI, it is now redundant to have ad-hoc
tests that check arbitrary things about our modules support. Instead,
the whole test suite should pass with modules enabled, period.
This patch also removes the module cache path workaround: one would
expect that modules work properly without that workaround. If that
isn't the case and we do run into flaky test failures, we can re-enable
the workaround temporarily (but that would be very vexing and we should
fix Clang ASAP if that's the case).
Differential Revision: https://reviews.llvm.org/D104746
* `<type_traits>` depends on `std::forward`, so we replaced it with
`static_cast<T&&>`.
* `swap`'s return type is confusing, so it's been rearranged to improve
readabilitiy.
* indicates whether work has been started or completed
* consolidates content that was split for dependency reasons (iff
everything has been merged)
* makes things a lot more fine-grained
* turns sub-CSVs into lists
* puts links into description section and removes patch column
* adds links to c++draft on occasion
These changes heavily prioritise the the reader of the generated HTML
file, not the source.
Differential Revision: https://reviews.llvm.org/D103295
C++03 didn't support `explicit` conversion operators;
but Clang's C++03 mode does, as an extension, so we can use it.
This lets us make the conversion explicit in `std::function` (even in '03),
and remove some silly metaprogramming in `std::basic_ios`.
Drive-by improvements to the tests for these operators, in addition
to making sure all these tests also run in `c++03` mode.
Differential Revision: https://reviews.llvm.org/D104682
The current implementation of `std::forward_list::swap` uses
`propagate_on_container_move_assignment` for `noexcept` specification.
This patch changes it to use `propagate_on_container_swap`, as it should.
Fixes https://llvm.org/PR50224.
Differential Revision: https://reviews.llvm.org/D101899
This is a fairly mechanical change, it just moves each algorithm into
its own header. This is intended to be a NFC.
This commit re-applies 7ed7d4ccb8, which was reverted in 692d7166f7
because the Modules build got broken. The modules build has now been
fixed, so we're re-committing this.
Differential Revision: https://reviews.llvm.org/D103583
Attribution note
----------------
I'm only committing this. This commit is a mix of D103583, D103330 and
D104171 authored by:
Co-authored-by: Christopher Di Bella <cjdb@google.com>
Co-authored-by: zoecarver <z.zoelec2@gmail.com>
P1518 does the following in C++23 but we'll just do it in C++17 as well:
- Stop requiring `Alloc` to be an allocator on some container-adaptor deduction guides
- Stop deducing from `Allocator` on some sequence container constructors
- Stop deducing from `Allocator` on some other container constructors (libc++ already did this)
The affected constructors are the "allocator-extended" versions of
constructors where the non-allocator arguments are already sufficient
to deduce the allocator type. For example,
std::pmr::vector<int> v1;
std::vector v2(v1, std::pmr::new_delete_resource());
std::stack s2(v1, std::pmr::new_delete_resource());
Differential Revision: https://reviews.llvm.org/D97742
When we removed the allocator<void> specialization, the triviality of
std::allocator<void> changed because the primary template had a
non-trivial default constructor and the specialization didn't
(so std::allocator<void> went from trivial to non-trivial).
This commit fixes that oversight by giving a trivial constructor to
the primary template when instantiated on cv-void.
This was reported in https://llvm.org/PR50299.
Differential Revision: https://reviews.llvm.org/D104398
A few slipped through the cracks because D104175 and D104170 didn't
concern themselves with newer commits.
Differential Revision: https://reviews.llvm.org/D104414
While the std::allocator<void> specialization was deprecated by
https://wg21.link/p0174#2.2, the *use* of std::allocator<void> by users
was not. The intent was that std::allocator<void> could still be used
in C++17 and C++20, but starting with C++20 (with the removal of the
specialization), std::allocator<void> would use the primary template.
That intent was called out in wg21.link/p0619r4#3.9.
As a result of this patch, _LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS
will also not control whether the explicit specialization is provided or
not. It shouldn't matter, since in C++20, one can simply use the primary
template.
Fixes http://llvm.org/PR50299
Differential Revision: https://reviews.llvm.org/D104323
Also, fix the last issue that prevented GCC 11 from passing the test
suite. Thanks to everyone else who fixed issues.
Differential Revision: https://reviews.llvm.org/D104315
This has been broken out of D104170 since it should be merged whether or
not we go ahead with the module map changes.
Differential Revision: https://reviews.llvm.org/D104175
https://eel.is/c++draft/atomics.types.operations#23 says: ... the value of failure is order except that a value of `memory_order::acq_rel` shall be replaced by the value `memory_order::acquire` and a value of `memory_order::release` shall be replaced by the value `memory_order::relaxed`.
This failure mapping is only handled for `_LIBCPP_HAS_GCC_ATOMIC_IMP`. We are seeing bad code generation for `compare_exchange_strong(cmp, 1, std::memory_order_acq_rel)` when using libc++ in place of libstdc++: https://godbolt.org/z/v3onrrq4G.
This was caught by tsan tests after D99434, `[TSAN] Honor failure memory orders in AtomicCAS`, but appears to be an issue in non-tsan code.
Reviewed By: ldionne, dvyukov
Differential Revision: https://reviews.llvm.org/D103846
The runtimes build has assertions enabled, which is necessary to catch
some of the modules-related issues we've been seeing recently. This
patch enables testing with modules in the runtimes build so as to cover
those cases.
In the future, a better solution would be to systematically use versions
of Clang that have assertions enabled. However, the Clangs we release
currently don't have assertions enabled by default, which causes a
challenge for the CI (we could try to build our own Clang from ToT with
assertions in the CI, but that poses some problems).
Differential Revision: https://reviews.llvm.org/D104252
This started as an attempt to fix a GCC 11 warning of misplaced parentheses.
I then noticed that trying to fix the parentheses warning actually triggered
errors in the tests, showing that we were incorrectly assuming that the
implementation of ranges::advance was using operator+= or operator-=.
This commit fixes that issue and makes the tests easier to follow by
localizing the assertions it makes.
Differential Revision: https://reviews.llvm.org/D103272
Louis Dionne