In 2cea1babefbb, we removed the <setjmp.h> header provided by libc++. However, we did not conditionally include the underlying <setjmp.h>
header only if the C library provides one, which we otherwise do consistently (see e.g. 647ddc08f43c).
rdar://122978778
This fixes two major mistakes in the implementation of
`linear_congruential_engine` that allowed it to produce incorrect
output. Specifically, these mistakes are in `__lce_alg_picker`, which is
used to determine whether Schrage's algorithm is valid and needed.
The first mistake is in the definition of `_OverflowOK`. The code
comment and the description of [D65041](https://reviews.llvm.org/D65041)
both indicate that it's supposed to be true iff `m` is a power of two.
However, the definition used does not work out to that, and instead is
true whenever `m` is even. This could result in
`linear_congruential_engine` using an invalid implementation, as it
would incorrectly assume that any integer overflow can't change the
result. I changed the implementation to one that accurately checks if
`m` is a power of two. Technically, this implementation has an edge case
where it considers `0` to be a power of two, but in this case this is
actually accurate behavior, as `m = 0` indicates a modulus of 2^w where
w is the size of `result_type` in bits, which *is* a power of two.
The second mistake is in the static assert. The original static assert
erroneously included an unnecessary `a != 0 || m != 0`. Combined with
the `|| !_MightOverflow`, this actually resulted in the static assert
being impossible to fail. Applying De Morgan's law and expanding
`_MightOverflow` gives that the only way this static assert can be
triggered is if `a == 0 && m == 0 && a != 0 && m != 0 && ...`, which
clearly cannot be true. I simply removed the explicit checks against `a`
and `m`, as the intended checks are already included in `_MightOverflow`
and `_SchrageOK`, and their inclusion doesn't provide any obvious
semantic benefit.
This should fix all the current instances where
`linear_congruential_engine` uses an invalid implementation. This
technically isn't a complete implementation, though, since the static
assert will cause some instantiations of `linear_congruential_engine`
not disallowed by the standard from compiling. However, this should
still be an improvement, as all compiling instantiations of
`linear_congruential_engine` should use a valid implementation. Fixing
the cases where the static assert triggers will require adding
additional implementations, some of which will be fairly non-trivial, so
I'd rather leave those for another PR so they don't hold up these more
important fixes.
Fixes#33554
This CMakeLists.txt is used to build modules without build system
support. This was removed in d06ae33ec32122bb526fb35025c1f0cf979f1090.
This is used in the documentation how to use modules.
Made some minor changes to make it work with the std.compat module using
the std module.
Note the CMakeLists.txt in the build dir should be removed once build
system support is generally available.
Having the test in the header requires including unistd.h on POSIX
platforms. This header has other declarations which may conflict with
code that uses named declarations provided by this header. For example
code using "int pipe;" would conflict with the function pipe in this
header.
Moving the code to the dylib means std::print would not be available on
Apple backdeployment targets. On POSIX platforms there is no transcoding
required so a not Standard conforming implementation is still a useful
and the observable differences are minimal. This behaviour has been done
for print before https://github.com/llvm/llvm-project/pull/76293.
Note questions have been raised in LWG4044 "Confusing requirements for
std::print on POSIX platforms", whether or not the isatty check on POSIX
platforms is required. When this LWG issue is resolved the
backdeployment targets could become Standard compliant.
This patch is intended to be backported to the LLVM-18 branch.
Fixes: https://github.com/llvm/llvm-project/issues/79782
Applies LWG3050 to the constraints of operator*, operator/, and
operator%. The changes to the constructor were done in
https://reviews.llvm.org/D118902, but that patch did not identify the
related LWG-issue, and only adjusted the constructor to the wording in
the Standard.
Implements:
- LWG 3050: Conversion specification problem in chrono::duration
constructor
---------
Co-authored-by: h-vetinari <h.vetinari@gmx.com>
On Windows the libc++ test suite sees the MSVC STL headers and may
conclude these are libc++ headers when inspecting the name. Modules
guard against forgetting to export new headers. Finding MSVC STL's
headers gives false positives. Since the CI tests non-Windows platforms
too, the validation will be disabled on Windows.
Fixes: https://github.com/llvm/llvm-project/issues/79010
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Some changes in libc++ affect the dylib. These changes are not present
on systems that use the system dylib. Currently that are the Apple
backdeployment targets. Figuring out which MacOS versions to target is
not trivial for non-Apple engineers. These shorthands make it easier to
select the proper feature make a test UNSUPPORTED or XFAIL.
During the design discussion with Louis we considered whether or not to
add preprocessor definitions to allow partial disabling of a test. This
would be useful when an existing feature is changed by modifying the
dylib. In the end we decided not to add this feature to avoid additional
complexity in the tests. Instead the test will be disabled for that
target.
The cv specializations for `numeric_limits` inherited privately for some
reason. We can simplify the implementation by inheriting publicly and
removing the members that just replicate the values from the base class.
This patch adds tests that lock down the ABI of types like deque, list
and vector.
An upcoming patch will replace the usage of __compressed_pair in these
classes
by [[no_unique_address]], so we are adding these tests to pin down their
ABI
before making the change. That way, we can be confident that the patch
making
the actual ABI-sensitive change is safe if it doesn't break these tests.
If the `_LIBCPP_HARDENING_MODE_DEFAULT` macro is not defined,
`_LIBCPP_HARDENING_MODE` will be considered defined but fail the check
for a valid hardening mode, resulting in a slightly less understandable
error (that error is really meant more to prevent users from passing
incorrect values such as `0` or `1` directly rather than catching
configuration issues).
#80558 introduced code that assumed that the element type of `vector` is
never const. This fixes it and adds a test. Eventually we should remove
the `allocator<const T>` extension.
The issue addresses an obvious wording issue. Implementing the
constructors as specified in the synposis, as libc++ did, already
implements the fixed behaviour.
Updates:
- LWG3346 pair and tuple copy and move constructor have backwards
specification
As of 4d20cfcf4eb08217ed37c4d4c38dc395d7a66d26, `__bit_reference`
contains a template `__fill_n` with a bool `_FillValue` parameter.
Unfortunately there is a relatively widely used piece of scientific
software called NetCDF, which exposes a (C) macro `_FillValue` in its
public headers.
When building the NetCDF C++ bindings, this quickly leads to compilation
errors when the macro interferes with the template in `__bit_reference`.
Rename the parameter to `_FillVal` to avoid the conflict.
We noticed that some feature-test macros were not conditional on
configuration flags like _LIBCPP_HAS_NO_FILESYSTEM. As a result, code
attempting to use FTMs would not work as intended.
This patch adds conditionals for a few feature-test macros, but more
issues may exist.
rdar://122020466
The valarray<>::operator[](...) const functions return proxy objects.
The valarray<>::operator[](...) functions return valarray objects.
However the standard allows functions returning valarray objects to
return custom proxy objects instead. Libc++ returns __val_expr proxies.
Functions taking a valarray object must work with the custom proxies
too. Therefore several operations have a custom proxy overload instead
of valarray overloads.
Libc++ doesn't specify a valarray overload. This is an issue with the
standard proxy types; these can implicitly be converted to a valarray.
The solution is to allow the standard proxies to behave as-if they are
custom proxies.
This patch fixes the valarray compound assignments. Other operations,
like the binary non-member functions are not fixed. These will be done
in a followup patch.
Fixes: https://github.com/llvm/llvm-project/issues/21320
This patch introduces a new trait to represent whether a type is
trivially
relocatable, and uses that trait to optimize the growth of a std::vector
of trivially relocatable objects.
```
--------------------------------------------------
Benchmark old new
--------------------------------------------------
bm_grow<int> 1354 ns 1301 ns
bm_grow<std::string> 5584 ns 3370 ns
bm_grow<std::unique_ptr<int>> 3506 ns 1994 ns
bm_grow<std::deque<int>> 27114 ns 27209 ns
```
This also changes to order of moving and destroying the objects when
growing the vector. This should not affect our conformance.
`non-lockfree-atomics` is very similar to `has-64-bit-atomics`; to
simplify, we can have uniform features for atomic types of
increasing sizes (`has-128-bit-atomics`, `has-256-bit-atomics`, etc.).
`is-lockfree-runtime-function` feature was a workaround for the partial
support for large atomic types on older versions of macOS (see
https://reviews.llvm.org/D91911). While we still support macOS 10.14,
conceptually it's simpler to check for support for all the atomic
functionality inside the `has-*-atomics` features, and the workaround is
no longer worth the maintenance cost.
