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 b

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

show more ...

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

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.

show more ...

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 n

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

show more ...

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

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

show more ...

[libc++] Remove test-suite annotations for unsupported Clang versions

Differential Revision: https://reviews.llvm.org/D108471

[libc++] Remove workarounds for the lack of deduction guides in C++17

All supported compilers have supported deduction guides in C++17 for a
while, so this isn't necessary anymore.

Differential Rev

[libc++] Remove workarounds for the lack of deduction guides in C++17

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

show more ...

[libc++] Remove the c++98 Lit feature from the test suite

C++98 and C++03 are effectively aliases as far as Clang is concerned.
As such, allowing both std=c++98 and std=c++03 as Lit parameters is
ju

[libc++] Remove the c++98 Lit feature from the test suite

C++98 and C++03 are effectively aliases as far as Clang is concerned.
As such, allowing both std=c++98 and std=c++03 as Lit parameters is
just slightly confusing, but provides no value. It's similar to allowing
both std=c++17 and std=c++1z, which we don't do.

This was discovered because we had an internal bot that ran the test
suite under both c++98 AND c++03 -- one of which is redundant.

Differential Revision: https://reviews.llvm.org/D80926

show more ...

[libc++] Mark CTAD tests as not failing on AppleClang 10.0.1

They do fail on AppleClang 10.0.0, but not AppleClang 10.0.1

llvm-svn: 372632

[libc++] Take 2: Implement CTAD for map and multimap

This is a re-application of r362986 (which was reverted in r363688) with fixes
for the issue that caused it to be reverted.

Thanks to Arthur O'D

[libc++] Take 2: Implement CTAD for map and multimap

This is a re-application of r362986 (which was reverted in r363688) with fixes
for the issue that caused it to be reverted.

Thanks to Arthur O'Dwyer for the patch.

Differential Revision: https://reviews.llvm.org/D58587

llvm-svn: 363968

show more ...

[libcxx] XFAIL some CTAD tests on AppleClang 10

AppleClang 10 doesn't contain some changes that are required for this
test to give the right error message.

llvm-svn: 363197

XFAIL a couple of tests on apple-clang-9.1, which is a compiler that I didn't know existed

llvm-svn: 363097

XFAIL a couple of CTAD tests on clang-6; it gives different error messages than clang 7/8/9

llvm-svn: 363014

Implement deduction guides for map/multimap. Reviewed as https://reviews.llvm.org/D58587. Thanks to Quuxplusone for the submission.

llvm-svn: 362986