7 Commits

Author SHA1 Message Date
Louis Dionne
72f0edf3f4 [libc++] Remove unnecessary main() function in .compile.pass.cpp and .verify.cpp tests
We pretty consistently don't define those cause they are not needed,
and it removes the potential pitfall to think that these tests are
being run. This doesn't touch .compile.fail.cpp tests since those
should be replaced by .verify.cpp tests anyway, and there would be
a lot to fix up.

As a fly-by, I also fixed a bit of formatting, removed a few unused
includes and made some very minor, clearly NFC refactorings such as
in allocator.traits/allocator.traits.members/allocate.verify.cpp where
the old test basically made no sense the way it was written.

Differential Revision: https://reviews.llvm.org/D146236
2023-03-17 17:56:21 -04:00
Muhammad Usman Shahid
76476efd68 Rewording "static_assert" diagnostics
This patch rewords the static assert diagnostic output. Failing a
_Static_assert in C should not report that static_assert failed. This
changes the wording to be more like GCC and uses "static assertion"
when possible instead of hard coding the name. This also changes some
instances of 'static_assert' to instead be based on the token in the
source code.

Differential Revision: https://reviews.llvm.org/D129048
2022-07-25 07:22:54 -04:00
Erich Keane
1da3119025 Revert "Rewording the "static_assert" to static assertion"
Looks like we again are going to have problems with libcxx tests that
are overly specific in their dependency on clang's diagnostics.

This reverts commit 6542cb55a3eb115b1c3592514590a19987ffc498.
2022-07-21 06:40:14 -07:00
Muhammad Usman Shahid
6542cb55a3 Rewording the "static_assert" to static assertion
This patch is basically the rewording of the static assert statement's
output(error) on screen after failing. Failing a _Static_assert in C
should not report that static_assert failed. It’d probably be better to
reword the diagnostic to be more like GCC and say “static assertion”
failed in both C and C++.

consider a c file having code

_Static_assert(0, "oh no!");

In clang the output is like:

<source>:1:1: error: static_assert failed: oh no!
_Static_assert(0, "oh no!");
^              ~
1 error generated.
Compiler returned: 1

Thus here the "static_assert" is not much good, it will be better to
reword it to the "static assertion failed" to more generic. as the gcc
prints as:

<source>:1:1: error: static assertion failed: "oh no!"
    1 | _Static_assert(0, "oh no!");
          | ^~~~~~~~~~~~~~
          Compiler returned: 1

The above can also be seen here. This patch is about rewording
the static_assert to static assertion.

Differential Revision: https://reviews.llvm.org/D129048
2022-07-21 06:34:14 -07:00
Louis Dionne
f599e7a789 [libc++] Refactor __perfect_forward, bind_front and not_fn
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
2021-08-09 15:32:00 -04:00
Louis Dionne
e35677c07c [libc++] NFC: Remove unused c++98 Lit feature 2021-06-22 16:24:43 -04:00
zoecarver
84a50f5911 [libc++] Add bind_front function (P0356R5).
Implementes [[ http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0356r5.html | P0356R5 ]]. Adds `bind_front` to `functional`.

Reviewed By: ldionne, #libc, Quuxplusone

Differential Revision: https://reviews.llvm.org/D60368
2021-03-02 16:18:06 -08:00