Commit Graph

9 Commits

Author SHA1 Message Date
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 6542cb55a3.
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
Corentin Jabot da1609ad73 Improve the formatting of static_assert messages
Display 'static_assert failed: message' instead of
'static_assert failed "message"' to be consistent
with other implementations and be slightly more
readable.

Reviewed By: #libc, aaron.ballman, philnik, Mordante

Differential Revision: https://reviews.llvm.org/D128844
2022-06-30 23:59:21 +02:00
Joe Loser d2baefae68
[libc++] Replace _LIBCPP_HAS_NO_CONCEPTS with _LIBCPP_STD_VER > 17. NFCI.
All supported compilers that support C++20 now support concepts. So, remove
`_LIB_LIBCPP_HAS_NO_CONCEPTS` in favor of `_LIBCPP_STD_VER > 17`. Similarly in
the tests, remove `// UNSUPPORTED: libcpp-no-concepts`.

Differential Revision: https://reviews.llvm.org/D121528
2022-03-13 12:32:06 -04:00
Louis Dionne 504bc07d1a [runtimes] Use int main(int, char**) consistently in tests
This is needed when running the tests in Freestanding mode, where main()
isn't treated specially. In Freestanding, main() doesn't get mangled as
extern "C", so whatever runtime we're using fails to find the entry point.

One way to solve this problem is to define a symbol alias from __Z4mainiPPc
to _main, however this requires all definitions of main() to have the same
mangling. Hence this commit.
2020-10-08 14:28:13 -04:00
Louis Dionne b5e896c049 [libc++][pstl] Remove c++98 from UNSUPPORTED annotations
c++98 isn't used by the test suite anymore, only c++03 is.
2020-07-29 14:17:32 -04:00
Raul Tambre 98eb1457ff [libc++] Require concepts support for <numbers>
Similar to <concepts>, we need to protect the header and test against
inclusion and being run if concepts aren't supported by the compiler.

Differential Revision: https://reviews.llvm.org/D82171
2020-06-19 10:49:44 -04:00
Raul Tambre 4f6c4b473c [libc++] Implement <numbers>
Summary: Constants have 33 significant decimal digits for IEEE 754 128-bit floating-point numbers.

Reviewers: ldionne, #libc, EricWF, zoecarver, curdeius

Reviewed By: ldionne, #libc, curdeius

Differential Revision: https://reviews.llvm.org/D77505
2020-06-19 14:25:02 +05:30