Rewording the "static_assert" to static assertion

[Codesbyusman]

Summary

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.

[xgupta]

Three test cases are failing - Please see: https://buildkite.com/llvm-project/premerge-checks/builds/100784#0181c539-bcd1-4d01-a2db-f27a63e2f17e/6-15379
But I think you want to actually modify https://github.com/llvm/llvm-project/blob/93d6fdfc232c59975d52146532693178def5ad16/clang/include/clang/Basic/DiagnosticSemaKinds.td#L11133 and https://github.com/llvm/llvm-project/blob/93d6fdfc232c59975d52146532693178def5ad16/clang/include/clang/Basic/DiagnosticSemaKinds.td#L11142.

Please also add more description to the patch as I said before like this -
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++.
For example -
cat test.c
_Static_assert(0, "oh no!");

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

while gcc
<source>:1:1: error: static assertion failed: "oh no!"

1 | _Static_assert(0, "oh no!");
Compiler returned: 1

clang/test/CXX/expr/expr.prim/expr.prim.req/nested-requirement.cpp

48

a 'newline' is missing here.

clang/test/CXX/temp/temp.constr/temp.constr.constr/partial-specializations.cpp

85

same

[Codesbyusman]

Updating the files as required

[Codesbyusman]

updating

[Codesbyusman]

All changes in one place

[Codesbyusman]

all changes in one patch revision

[Codesbyusman]

all

[Codesbyusman]

update

[Codesbyusman]

new changes as required -- final

[aaron.ballman]

Thank you for getting a great start on this diagnostic rewording!

I think we should also update DiagnosticParseKinds.td at the same time, but because that's about parsing rather than semantics, not all of the diagnostics should be reworded to use "static assertion".

err_expected_semi_after_static_assert should switch to use %0 and pass in the actual parsed token -- I am pretty sure (but not 100% sure because I didn't try this myself) that it will print the actual spelling used for the token in that case.

warn_cxx98_compat_static_assert should get single quotes around the static_assert in the message, but is otherwise fine.

ext_ms_static_assert, ext_cxx_static_assert_no_message, ext_c_static_assert_no_message, warn_cxx14_compat_static_assert_no_message, warn_c17_compat_static_assert_no_message, and err_templated_invalid_declaration are all fine as-is.

clang/include/clang/Basic/DiagnosticSemaKinds.td

11133

This is a case where the original text was slightly better -- this diagnostic is only issued for C++ code (modules don't exist in C), so using static_assert was fine.

11142

Same is true here.

[Codesbyusman]

updating some to the back strings becaue the orginal were more better

[Codesbyusman]

updating the test files for the last update

[aaron.ballman]

Precommit CI failures currently look to be unrelated. I think the only thing remaining is this bit:

I think we should also update DiagnosticParseKinds.td at the same time...

[Codesbyusman]

Yes I am looking into the DiagnosticParseKinds.td

[Codesbyusman]

Yes I am looking into the DiagnosticParseKinds.td. Kindly also look another error encountered in testing while updating the test. Although not having in my system but this is giving .
Look here

[aaron.ballman]

In D129048#3630584, @Codesbyusman wrote:

Yes I am looking into the DiagnosticParseKinds.td

Excellent, thank you!

In D129048#3630589, @Codesbyusman wrote:

Yes I am looking into the DiagnosticParseKinds.td. Kindly also look another error encountered in testing while updating the test. Although not having in my system but this is giving .
Look here

I noticed that one earlier -- I think it's unrelated to your changes. (I've seen that test spuriously fail before and there's nothing in the test files that uses a static assertion, so it seems highly unlikely that changes to the diagnostic message caused that issue; I expect it will go away on its own when you push up another patch in the future.) I think it's safe for you to ignore.

[Codesbyusman]

the parser updates maked for the static asserion

[aaron.ballman]

I think this is getting pretty close! I did have some style guideline changes, and at least one test addition I'd like to see though. Also, it looks like precommit CI caught a test that still needs to be updated:

FAIL: Clang :: SemaCXX/cxx98-compat.cpp (16448 of 68726)

******************** TEST 'Clang :: SemaCXX/cxx98-compat.cpp' FAILED ********************

Script:

--

: 'RUN: at line 1';   /var/lib/buildkite-agent/builds/llvm-project/build/bin/clang -cc1 -internal-isystem /var/lib/buildkite-agent/builds/llvm-project/build/lib/clang/15.0.0/include -nostdsysteminc -fsyntax-only -std=c++11 -Wc++98-compat -verify /var/lib/buildkite-agent/builds/llvm-project/clang/test/SemaCXX/cxx98-compat.cpp

: 'RUN: at line 2';   /var/lib/buildkite-agent/builds/llvm-project/build/bin/clang -cc1 -internal-isystem /var/lib/buildkite-agent/builds/llvm-project/build/lib/clang/15.0.0/include -nostdsysteminc -fsyntax-only -std=c++14 -Wc++98-compat -verify /var/lib/buildkite-agent/builds/llvm-project/clang/test/SemaCXX/cxx98-compat.cpp -DCXX14COMPAT

: 'RUN: at line 3';   /var/lib/buildkite-agent/builds/llvm-project/build/bin/clang -cc1 -internal-isystem /var/lib/buildkite-agent/builds/llvm-project/build/lib/clang/15.0.0/include -nostdsysteminc -fsyntax-only -std=c++17 -Wc++98-compat -verify /var/lib/buildkite-agent/builds/llvm-project/clang/test/SemaCXX/cxx98-compat.cpp -DCXX14COMPAT -DCXX17COMPAT

--

Exit Code: 1



Command Output (stderr):

--

error: 'warning' diagnostics expected but not seen: 

  File /var/lib/buildkite-agent/builds/llvm-project/clang/test/SemaCXX/cxx98-compat.cpp Line 155: static_assert declarations are incompatible with C++98

error: 'warning' diagnostics seen but not expected: 

  File /var/lib/buildkite-agent/builds/llvm-project/clang/test/SemaCXX/cxx98-compat.cpp Line 155: 'static_assert' declarations are incompatible with C++98

2 errors generated.



--



********************

clang/include/clang/Basic/DiagnosticParseKinds.td

285 ↗

(On Diff #444211)

I think we're missing some test coverage, because I would have expected at least one test to fail because of this change. I think you should add a test to clang/test/SemaCXX/static-assert.cpp like this:

static_assert(1, "")
_Static_assert(1, "")

where the semi colons are missing, and add the correct expected-error lines to each so that we have coverage for your changes.

clang/include/clang/Parse/Parser.h

1046 ↗

(On Diff #444211)

clang/lib/Parse/ParseDeclCXX.cpp

930 ↗

(On Diff #444211)

994–998 ↗

(On Diff #444211)

You should also make sure this fits in the usual 80-col limit and if it doesn't, clang-format the patch (https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting).

clang/lib/Parse/Parser.cpp

156–175 ↗

(On Diff #444211)

[Codesbyusman]

updated the styles and other small things

[Codesbyusman]

In D129048#3647918, @aaron.ballman wrote:

I think this is getting pretty close! I did have some style guideline changes, and at least one test addition I'd like to see though. Also, it looks like precommit CI caught a test that still needs to be updated:

FAIL: Clang :: SemaCXX/cxx98-compat.cpp (16448 of 68726)

******************** TEST 'Clang :: SemaCXX/cxx98-compat.cpp' FAILED ********************

Script:

--

: 'RUN: at line 1';   /var/lib/buildkite-agent/builds/llvm-project/build/bin/clang -cc1 -internal-isystem /var/lib/buildkite-agent/builds/llvm-project/build/lib/clang/15.0.0/include -nostdsysteminc -fsyntax-only -std=c++11 -Wc++98-compat -verify /var/lib/buildkite-agent/builds/llvm-project/clang/test/SemaCXX/cxx98-compat.cpp

: 'RUN: at line 2';   /var/lib/buildkite-agent/builds/llvm-project/build/bin/clang -cc1 -internal-isystem /var/lib/buildkite-agent/builds/llvm-project/build/lib/clang/15.0.0/include -nostdsysteminc -fsyntax-only -std=c++14 -Wc++98-compat -verify /var/lib/buildkite-agent/builds/llvm-project/clang/test/SemaCXX/cxx98-compat.cpp -DCXX14COMPAT

: 'RUN: at line 3';   /var/lib/buildkite-agent/builds/llvm-project/build/bin/clang -cc1 -internal-isystem /var/lib/buildkite-agent/builds/llvm-project/build/lib/clang/15.0.0/include -nostdsysteminc -fsyntax-only -std=c++17 -Wc++98-compat -verify /var/lib/buildkite-agent/builds/llvm-project/clang/test/SemaCXX/cxx98-compat.cpp -DCXX14COMPAT -DCXX17COMPAT

--

Exit Code: 1



Command Output (stderr):

--

error: 'warning' diagnostics expected but not seen: 

  File /var/lib/buildkite-agent/builds/llvm-project/clang/test/SemaCXX/cxx98-compat.cpp Line 155: static_assert declarations are incompatible with C++98

error: 'warning' diagnostics seen but not expected: 

  File /var/lib/buildkite-agent/builds/llvm-project/clang/test/SemaCXX/cxx98-compat.cpp Line 155: 'static_assert' declarations are incompatible with C++98

2 errors generated.



--



********************

I just make some changes in the cxx98-compact.cpp and test was passed I was missing to update the expected-error comment for this.

[Codesbyusman]

the tests for the coverage of changes being made for the static assertion

[erichkeane]

A couple of comment suggestions, our comments use a full-stop.

[erichkeane]

clang/lib/Parse/ParseDeclCXX.cpp

929 ↗

(On Diff #444284)

995 ↗

(On Diff #444284)

[Codesbyusman]

updated the comment styles suggested

[aaron.ballman]

clang/lib/Parse/ParseDeclCXX.cpp

929 ↗

(On Diff #444311)

995 ↗

(On Diff #444311)

My suggestion is slightly different from Erich's (mine has whitespace and capitalization fixes), also, this is definitely over the 80 col limit, so you should format the patch.

clang/test/CXX/expr/expr.prim/expr.prim.req/nested-requirement.cpp

48

Still missing the newline at the end of the file here.

clang/test/CXX/temp/temp.constr/temp.constr.constr/partial-specializations.cpp

85

Same here

[erichkeane]

clang/lib/Parse/ParseDeclCXX.cpp

995 ↗

(On Diff #444311)

Ah, missed that <3

[Codesbyusman]

updated the format issues

[Codesbyusman]

clang/test/CXX/expr/expr.prim/expr.prim.req/nested-requirement.cpp

48

what here is mean by the missing line I am adding the newline but no changes to the comment

No newline at end of file

[aaron.ballman]

clang/test/CXX/expr/expr.prim/expr.prim.req/nested-requirement.cpp

48

C++ used to have a requirement that every file end with a newline (C still has that requirement), so Phabricator is reminding you that the file should still end in a newline. The fix is to put a newline after the closing curly brace on line 47 (so the newline is line 48).

[Codesbyusman]

updating new lines

[Codesbyusman]

Done.

[erichkeane]

Please format your patch with clang-format. See the command at the end of this: https://clang.llvm.org/docs/ClangFormat.html

git diff -U0 --color=never | clang-format-diff.py -i -p1

[Codesbyusman]

run the clang-format

[Codesbyusman]

In D129048#3648964, @erichkeane wrote:

Please format your patch with clang-format. See the command at the end of this: https://clang.llvm.org/docs/ClangFormat.html

git diff -U0 --color=never | clang-format-diff.py -i -p1

Done

[aaron.ballman]

The changes here LGTM aside from one thing (which I'll take care of when I land the changes on your behalf). ParseDeclCXX.cpp still has a bunch of unrelated whitespace changes in it which should be backed out. We don't want unrelated changes sneaking in to a commit because that makes a future git blame that much harder on folks. But, rather than have you fiddle with it, I can strip them easily enough on my end, so this is just something to keep in mind for next time.

Thank you for the cleanup here!

[Codesbyusman]

ok. I will take care of this next time. Thank you.

[hctim]

Looks like unfortunately this breaks all lots of libcxx tests - which were picked up by our sanitizer buildbots:

https://lab.llvm.org/buildbot/#/builders/85/builds/9157

Should be reproducible with just cmake -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi" && make check-cxx.

An example:

******************** TEST 'llvm-libc++-shared.cfg.in :: std/utilities/format/format.formatter/format.parse.ctx/ch
eck_arg_id.verify.cpp' FAILED ********************                                                               
Script:                                                                                                          
--                                                                                                               
: 'COMPILED WITH';  /llvm-build/opt/./bin/clang++ /llvm
/libcxx/test/std/utilities/format/format.formatter/format.parse.ctx/check_arg_id.verify.cpp  --target=x86_64-unkn
own-linux-gnu -nostdinc++ -I /llvm-build/opt/include/c++/v1 -I /llvm-build/opt/include/x86_64-unknown-linux-gnu/c++/v1 -I /llvm/libcxx/test
/support -std=c++2b -Werror -Wall -Wextra -Wshadow -Wundef -Wno-unused-command-line-argument -Wno-attributes -Wno
-pessimizing-move -Wno-c++11-extensions -Wno-noexcept-type -Wno-atomic-alignment -Wno-user-defined-literals -Wno-
tautological-compare -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code -Wno-unused-local-typ
edef -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D_LIBCPP_ENABLE_EXPERIMENTAL -D_LIBCPP_DISABLE_AVAILABILITY -fcorouti
nes-ts -Werror=thread-safety -Wuser-defined-warnings  -fsyntax-only -Wno-error -Xclang -verify -Xclang -verify-ig
nore-unexpected=note -ferror-limit=0                                                                             
--                                                                                                               
Exit Code: 1                                                                                                     
                                                                                                                 
Command Output (stdout):                                                                                         
--                                                                                                               
$ ":" "COMPILED WITH"                                                                                            
$ "/llvm-build/opt/./bin/clang++" "/llvm/libcxx/test/st
d/utilities/format/format.formatter/format.parse.ctx/check_arg_id.verify.cpp" "--target=x86_64-unknown-linux-gnu"
 "-nostdinc++" "-I" "/llvm-build/opt/include/c++/v1" "-I" "/llvm-build/opt/include/x86_64-unknown-linux-gnu/c++/v1" "-I" "/llvm/libcxx/test
/support" "-std=c++2b" "-Werror" "-Wall" "-Wextra" "-Wshadow" "-Wundef" "-Wno-unused-command-line-argument" "-Wno
-attributes" "-Wno-pessimizing-move" "-Wno-c++11-extensions" "-Wno-noexcept-type" "-Wno-atomic-alignment" "-Wno-u
ser-defined-literals" "-Wno-tautological-compare" "-Wsign-compare" "-Wunused-variable" "-Wunused-parameter" "-Wun
reachable-code" "-Wno-unused-local-typedef" "-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER" "-D_LIBCPP_ENABLE_EXPERIMENTA
L" "-D_LIBCPP_DISABLE_AVAILABILITY" "-fcoroutines-ts" "-Werror=thread-safety" "-Wuser-defined-warnings" "-fsyntax
-only" "-Wno-error" "-Xclang" "-verify" "-Xclang" "-verify-ignore-unexpected=note" "-ferror-limit=0"             
# command stderr:                                                                                                
error: 'error' diagnostics expected but not seen:                                                                
  File llvm/libcxx/test/std/utilities/format/format.formatter/format.parse.ctx/chec
k_arg_id.verify.cpp Line 29: static assertion expression is not an integral constant expression                  
2 errors generated.                                                                                              
                                                                                                                 
error: command failed with exit status: 1                                                                        
                                                                                                                 
--

[aaron.ballman]

In D129048#3652679, @hctim wrote:

Looks like unfortunately this breaks all lots of libcxx tests - which were picked up by our sanitizer buildbots:

Thanks for letting us know. Do you happen to know if there's any particular reason why no email was sent out for the build failure?

[hctim]

In D129048#3652689, @aaron.ballman wrote:

In D129048#3652679, @hctim wrote:

Looks like unfortunately this breaks all lots of libcxx tests - which were picked up by our sanitizer buildbots:

Thanks for letting us know. Do you happen to know if there's any particular reason why no email was sent out for the build failure?

No, sorry. Did it not get sent to [e-mail]? I see you committed it, but their address is the author of the commit.

[aaron.ballman]

In D129048#3652739, @hctim wrote:

In D129048#3652689, @aaron.ballman wrote:

In D129048#3652679, @hctim wrote:

Looks like unfortunately this breaks all lots of libcxx tests - which were picked up by our sanitizer buildbots:

Thanks for letting us know. Do you happen to know if there's any particular reason why no email was sent out for the build failure?

No, sorry. Did it not get sent to [e-mail]? I see you committed it, but their address is the author of the commit.

That's possible, but I recall getting build failure emails before when I've committed on someone's behalf. Oh well, thanks for letting us know and sorry for the breakage!

[ldionne]

Most of the libc++ CI testing happens on BuildKite, and we only trigger the libc++ buildkite pipeline if files in libcxx/ (and a few others) have changed. This wasn't the case here. If you want to re-land without breaking libc++, you'd have to go through libc++'s .verify.cpp tests and change the regex that we look for.

[Codesbyusman]

the libcxx updates but not tested. working on them

[xgupta]

In D129048#3662634, @Codesbyusman wrote:

the libcxx updates but not tested. working on them

I just run the check-cxx on local system. It seems to pass all testcases after applying the current patch.

Testing Time: 2147.75s

Unsupported      :  307
Passed           : 7184
Expectedly Failed:   41

[Codesbyusman]

In D129048#3662972, @xgupta wrote:

In D129048#3662634, @Codesbyusman wrote:

the libcxx updates but not tested. working on them

I just run the check-cxx on local system. It seems to pass all testcases after applying the current patch.

Testing Time: 2147.75s

Unsupported      :  307
Passed           : 7184
Expectedly Failed:   41

Thanks @xgupta

[erichkeane]

Tests ran clean for me as well. Looking at the CI, it appears that the libcxx tests are improperly configured, and are being run against an 'older' version of the compiler (not including this patch).

[philnik]

In D129048#3668542, @erichkeane wrote:

Tests ran clean for me as well. Looking at the CI, it appears that the libcxx tests are improperly configured, and are being run against an 'older' version of the compiler (not including this patch).

The libc++ CI isn't misconfigured. libc++ supports older clang versions. Please revert this and fix the tests. You should be able to use a regex.

[philnik]

Also, please wait for #libc approval next time.

[ldionne]

In D129048#3668594, @philnik wrote:

Also, please wait for #libc approval next time.

This, x1000.

We go through the trouble of having excellent pre-commit testing and automatic review groups assigned to reviews, please don't bypass that.

[aaron.ballman]

In D129048#3668846, @ldionne wrote:

In D129048#3668594, @philnik wrote:

Also, please wait for #libc approval next time.

This, x1000.

We go through the trouble of having excellent pre-commit testing and automatic review groups assigned to reviews, please don't bypass that.

We certainly will keep this in mind for the future, thanks for pointing it out! However, the precommit CI behavior confused multiple Clang contributors (I also thought the bot was misconfigured because Clang tests are never run against old Clang versions), the output did not clearly identify what was wrong or how to address it, and the difficulties with testing this locally are all things the libc++ maintainers should also keep in mind.

[Mordante]

In D129048#3668905, @aaron.ballman wrote:

In D129048#3668846, @ldionne wrote:

In D129048#3668594, @philnik wrote:

Also, please wait for #libc approval next time.

This, x1000.

We go through the trouble of having excellent pre-commit testing and automatic review groups assigned to reviews, please don't bypass that.

We certainly will keep this in mind for the future, thanks for pointing it out! However, the precommit CI behavior confused multiple Clang contributors (I also thought the bot was misconfigured because Clang tests are never run against old Clang versions), the output did not clearly identify what was wrong or how to address it, and the difficulties with testing this locally are all things the libc++ maintainers should also keep in mind.

What can we do to make it easier for Clang contributors to understand the libc++ CI?
Maybe we can discuss it on Discord.

libcxx/test/libcxx/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_add.verify.cpp

49 ↗

(On Diff #446469)

All libc++ tests need a regex accepting both the old and new diagnostic. Since we support older Clang versions.

[aaron.ballman]

In D129048#3669069, @Mordante wrote:

In D129048#3668905, @aaron.ballman wrote:

In D129048#3668846, @ldionne wrote:

In D129048#3668594, @philnik wrote:

Also, please wait for #libc approval next time.

This, x1000.

We go through the trouble of having excellent pre-commit testing and automatic review groups assigned to reviews, please don't bypass that.

We certainly will keep this in mind for the future, thanks for pointing it out! However, the precommit CI behavior confused multiple Clang contributors (I also thought the bot was misconfigured because Clang tests are never run against old Clang versions), the output did not clearly identify what was wrong or how to address it, and the difficulties with testing this locally are all things the libc++ maintainers should also keep in mind.

What can we do to make it easier for Clang contributors to understand the libc++ CI?
Maybe we can discuss it on Discord.

That's a great question to be asking, so thank you! I'm not on Discord (still on IRC though), but I'm happy to chat about it via whatever means works for us.

At a high-level, I think it boils down to familiarity. If we can get the libc++ CI to run as part of precommit CI (assuming precommit CI can be made to run with reliable results, which is a bit of a question mark), then I think that will help get all clang contributors more familiar with the libc++ testing behavior over time, because we'll be far more used to seeing it when we cause a failure. It would have also helped to catch the cause for the initial revert where everyone thought the patch was ready to land. Another thing that would help would be to get the libc++ test bots into the LLVM lab (https://lab.llvm.org/buildbot/#/builders) and ensure that they're sending failure emails to everyone on the blame list including people who land a patch on behalf of others. It looks like we have one builder for libc++, but it doesn't appear to be working recently: https://lab.llvm.org/buildbot/#/builders/156.

[Mordante]

In D129048#3669568, @aaron.ballman wrote:

In D129048#3669069, @Mordante wrote:

In D129048#3668905, @aaron.ballman wrote:

In D129048#3668846, @ldionne wrote:

In D129048#3668594, @philnik wrote:

Also, please wait for #libc approval next time.

This, x1000.

We go through the trouble of having excellent pre-commit testing and automatic review groups assigned to reviews, please don't bypass that.

We certainly will keep this in mind for the future, thanks for pointing it out! However, the precommit CI behavior confused multiple Clang contributors (I also thought the bot was misconfigured because Clang tests are never run against old Clang versions), the output did not clearly identify what was wrong or how to address it, and the difficulties with testing this locally are all things the libc++ maintainers should also keep in mind.

What can we do to make it easier for Clang contributors to understand the libc++ CI?
Maybe we can discuss it on Discord.

That's a great question to be asking, so thank you! I'm not on Discord (still on IRC though), but I'm happy to chat about it via whatever means works for us.

At a high-level, I think it boils down to familiarity. If we can get the libc++ CI to run as part of precommit CI (assuming precommit CI can be made to run with reliable results, which is a bit of a question mark), then I think that will help get all clang contributors more familiar with the libc++ testing behavior over time, because we'll be far more used to seeing it when we cause a failure. It would have also helped to catch the cause for the initial revert where everyone thought the patch was ready to land. Another thing that would help would be to get the libc++ test bots into the LLVM lab (https://lab.llvm.org/buildbot/#/builders) and ensure that they're sending failure emails to everyone on the blame list including people who land a patch on behalf of others. It looks like we have one builder for libc++, but it doesn't appear to be working recently: https://lab.llvm.org/buildbot/#/builders/156.

As @ldionne said we mainly use a pre-commit CI instead of a post-commit CI. I agree that it's probably a lack of familiarity, so let's try to remedy that. That will make everybody happier.

I'll reach out to you on IRC either tomorrow or next week. Then we can discuss how we can get the clang contributors more familiar with libc++'s way of testing.

[ldionne]

The libc++ CI runs pre-commit only, and it runs on all commits that touch something under libcxx/, libcxxabi/, runtimes/ and libunwind/. In particular, it won't trigger if you make changes to clang/ only -- that would create too much traffic and concretely it wouldn't help much, as we're rarely broken by Clang changes (this is an exception). Once the tests under libcxx/ were touched, the libc++ CI triggered, I found this build for instance: https://buildkite.com/llvm-project/libcxx-ci/builds/12210. I do think it boils down to familiarity -- while the Clang pre-commit CI is sometimes overlooked because it fails spuriously, the libc++ CI usually doesn't, so when it fails, there's usually a good reason. I do understand why someone mostly familiar with the Clang workflow could think they needed to be overlooked, though.

Concretely, libc++ supports the two latest releases of Clang, and so the CI tests against those. In fact, we run most of the tests using pre-installed Clangs since it allows us to bypass building Clang itself, which is a necessary optimization in the current setup. Regarding the tests themselves, I am able to find the following kind of output in the CI job that failed:

FAIL: llvm-libc++-shared.cfg.in :: std/numerics/numbers/illformed.verify.cpp (4388 of 7532)
[...]
error: 'error' diagnostics expected but not seen:
  File /home/libcxx-builder/.buildkite-agent/builds/2b1c77dd9e90-1/llvm-project/libcxx-ci/build/generic-cxx2b/include/c++/v1/numbers Line * (directive at /home/libcxx-builder/.buildkite-agent/builds/2b1c77dd9e90-1/llvm-project/libcxx-ci/libcxx/test/std/numerics/numbers/illformed.verify.cpp:15): static assertion failed{{.*}}A program that instantiates a primary template of a mathematical constant variable template is ill-formed.
error: 'error' diagnostics seen but not expected:
  File /home/libcxx-builder/.buildkite-agent/builds/2b1c77dd9e90-1/llvm-project/libcxx-ci/build/generic-cxx2b/include/c++/v1/numbers Line 83: static_assert failed due to requirement '__false<int>' "A program that instantiates a primary template of a mathematical constant variable template is ill-formed."
2 errors generated.

IMO this is reasonable output, in fact it's pretty much as good as we could have had. So I'm not taking any action item regarding improving the output of our CI, but I'm entirely open to suggestions if somebody has some.

In D129048#3669568, @aaron.ballman wrote:

At a high-level, I think it boils down to familiarity. If we can get the libc++ CI to run as part of precommit CI (assuming precommit CI can be made to run with reliable results, which is a bit of a question mark),

It is pretty reliable. However, I don't think it'll ever become reasonable to run the full libc++ CI on every Clang patch due to resource limitations.

It would have also helped to catch the cause for the initial revert where everyone thought the patch was ready to land.

100% agreed, however this is blocked on the resource limitations mentioned above. I guess one thing we could do here is trigger a simple bootstrapping build of Clang and run the libc++ tests in a single configuration even on changes to clang/. That might catch most issues and perhaps that would be small enough to be scalable. I'll experiment with that after the release.

Another thing that would help would be to get the libc++ test bots into the LLVM lab (https://lab.llvm.org/buildbot/#/builders)

Libc++ CI is pre-commit, the lab is post-commit only AFAICT. I also don't know whether there's a way to bridge between BuildKite and BuildBot, and what that would look like. So while I share the desire to have a single place to look for all LLVM wide CI, I'm not sure it is possible given the variety of technologies used.

and ensure that they're sending failure emails to everyone on the blame list including people who land a patch on behalf of others.

100% agreed here -- this is one problem with our current setup.

It looks like we have one builder for libc++, but it doesn't appear to be working recently: https://lab.llvm.org/buildbot/#/builders/156.

Yeah, this one needs to be removed, it's a remnant of when we used to have libc++ CI on BuildBot.

Okay, so to summarize:

1. I'll experiment with a simple job that runs the libc++ pre-commit CI on every patch to Clang. We'll see if that scales.
2. I'll look into sending blame emails from the ongoing (every 3h) job that runs the whole libc++ CI. This is basically equivalent to the buildbot functionality and it's arguably something that we're missing here. I have no idea how to do that, though, but it must be possible.
3. Usually, for these types of failures, we actually notice and fix it on our end without requesting a revert. For this kind of change, my opinion is that the burden of fixing the code should have been on us, kind of like when the LLDB data formatters break because we made a totally legal change in libc++. Nobody jumped in to fix it on the libc++ side this time because (I assume) we're racing for the release, but normally I or someone else would have chimed in to fix this without annoying Clang.
4. That being said, let's try to spread the word that when the libc++ tests do fail on a Clang patch (which implies that libcxx/ will have been touched until (1) is done), they must not be ignored.

[aaron.ballman]

In D129048#3670212, @ldionne wrote:

The libc++ CI runs pre-commit only, and it runs on all commits that touch something under libcxx/, libcxxabi/, runtimes/ and libunwind/. In particular, it won't trigger if you make changes to clang/ only -- that would create too much traffic and concretely it wouldn't help much, as we're rarely broken by Clang changes (this is an exception). Once the tests under libcxx/ were touched, the libc++ CI triggered, I found this build for instance: https://buildkite.com/llvm-project/libcxx-ci/builds/12210. I do think it boils down to familiarity -- while the Clang pre-commit CI is sometimes overlooked because it fails spuriously, the libc++ CI usually doesn't, so when it fails, there's usually a good reason. I do understand why someone mostly familiar with the Clang workflow could think they needed to be overlooked, though.

Thanks for the explanation!

FWIW, the specific reason why I overloooked it was because of running against old versions of Clang -- I saw the diagnostic was correct in the test and presumed that the old clang was a bot configuration issue. It definitely doesn't help that Clang's precommit CI tends to be spuriously broken quite often; it's trained some of us reviewers to be more dismissive of failing precommit CI than we should.

Concretely, libc++ supports the two latest releases of Clang, and so the CI tests against those. In fact, we run most of the tests using pre-installed Clangs since it allows us to bypass building Clang itself, which is a necessary optimization in the current setup. Regarding the tests themselves, I am able to find the following kind of output in the CI job that failed:

Yeah, which makes a lot of sense for libc++!

FAIL: llvm-libc++-shared.cfg.in :: std/numerics/numbers/illformed.verify.cpp (4388 of 7532)
[...]
error: 'error' diagnostics expected but not seen:
  File /home/libcxx-builder/.buildkite-agent/builds/2b1c77dd9e90-1/llvm-project/libcxx-ci/build/generic-cxx2b/include/c++/v1/numbers Line * (directive at /home/libcxx-builder/.buildkite-agent/builds/2b1c77dd9e90-1/llvm-project/libcxx-ci/libcxx/test/std/numerics/numbers/illformed.verify.cpp:15): static assertion failed{{.*}}A program that instantiates a primary template of a mathematical constant variable template is ill-formed.
error: 'error' diagnostics seen but not expected:
  File /home/libcxx-builder/.buildkite-agent/builds/2b1c77dd9e90-1/llvm-project/libcxx-ci/build/generic-cxx2b/include/c++/v1/numbers Line 83: static_assert failed due to requirement '__false<int>' "A program that instantiates a primary template of a mathematical constant variable template is ill-formed."
2 errors generated.

IMO this is reasonable output, in fact it's pretty much as good as we could have had. So I'm not taking any action item regarding improving the output of our CI, but I'm entirely open to suggestions if somebody has some.

I don't have a concrete suggestion for the CI output itself -- the failure was clear in retrospect, this was more a matter of not being familiar with the testing practices used.

In D129048#3669568, @aaron.ballman wrote:

At a high-level, I think it boils down to familiarity. If we can get the libc++ CI to run as part of precommit CI (assuming precommit CI can be made to run with reliable results, which is a bit of a question mark),

It is pretty reliable. However, I don't think it'll ever become reasonable to run the full libc++ CI on every Clang patch due to resource limitations.

The resource limitations are certainly a pragmatic thing for us to be concerned with, but I hope we're able to find some happy middle ground.

It would have also helped to catch the cause for the initial revert where everyone thought the patch was ready to land.

100% agreed, however this is blocked on the resource limitations mentioned above. I guess one thing we could do here is trigger a simple bootstrapping build of Clang and run the libc++ tests in a single configuration even on changes to clang/. That might catch most issues and perhaps that would be small enough to be scalable. I'll experiment with that after the release.

Thanks, that would be really beneficial. It's not just diagnostic wording changes that cause Clang developers problems with libc++ reverts; I've also seen C++20 work reverted because it broke libc++ without anyone in Clang knowing about it until after it landed (most recently, it's with the deferred concept checking work done by @erichkeane).

Another thing that would help would be to get the libc++ test bots into the LLVM lab (https://lab.llvm.org/buildbot/#/builders)

Libc++ CI is pre-commit, the lab is post-commit only AFAICT.

Correct, but right now we have no community testing for libc++ whatsoever from the perspective of Clang folks. We only find out about failures when libc++ folks start reverting or pointing them out.

I also don't know whether there's a way to bridge between BuildKite and BuildBot, and what that would look like. So while I share the desire to have a single place to look for all LLVM wide CI, I'm not sure it is possible given the variety of technologies used.

I don't know enough about the technology to know if it's easy or hard, unfortunately.

and ensure that they're sending failure emails to everyone on the blame list including people who land a patch on behalf of others.

100% agreed here -- this is one problem with our current setup.

It looks like we have one builder for libc++, but it doesn't appear to be working recently: https://lab.llvm.org/buildbot/#/builders/156.

Yeah, this one needs to be removed, it's a remnant of when we used to have libc++ CI on BuildBot.

Okay, so to summarize:

1. I'll experiment with a simple job that runs the libc++ pre-commit CI on every patch to Clang. We'll see if that scales.

Thanks, that would be awesome if it works out!

2. I'll look into sending blame emails from the ongoing (every 3h) job that runs the whole libc++ CI. This is basically equivalent to the buildbot functionality and it's arguably something that we're missing here. I have no idea how to do that, though, but it must be possible.

Thank you!!

3. Usually, for these types of failures, we actually notice and fix it on our end without requesting a revert. For this kind of change, my opinion is that the burden of fixing the code should have been on us, kind of like when the LLDB data formatters break because we made a totally legal change in libc++. Nobody jumped in to fix it on the libc++ side this time because (I assume) we're racing for the release, but normally I or someone else would have chimed in to fix this without annoying Clang.

FWIW, I've convinced myself that I agree with you here that the burden probably should have been on libc++ maintainers in this case. libc++ almost feels more like a downstream consumer of Clang in terms of testing needs, so I think when tests break because Clang diagnostic wording or behavior changes in a standards conforming way, libc++ folks should address it, but if Clang changes in a way that's not standards conforming, then Clang folks should address it. (Roughly speaking.) That said, I absolutely think we all need to continue to collaborate closely with one another as best we can when issues arise, and I really appreciate the discussion on how we can do that!

For this particular issue, I'd like @Codesbyusman to continue to try to fix the libc++ testing issues (it's good experience), but if that takes significantly longer (say, more than 8 hours of his effort), perhaps @ldionne or someone else from libc++ will have a moment to step in to help? (For reference, Usman is a Google Summer of Code mentee and this was his first patch for Clang. I think this has been a really good way for him to see how open source collaborations work in practice but I also don't want him to get bogged down too much if I can help it. Normally I'd step in to help directly, but I've been in WG14 meetings all week and so I am pretty swamped at the moment.)

4. That being said, let's try to spread the word that when the libc++ tests do fail on a Clang patch (which implies that libcxx/ will have been touched until (1) is done), they must not be ignored.

Absolutely!

[ldionne]

In D129048#3671568, @aaron.ballman wrote:

FWIW, I've convinced myself that I agree with you here that the burden probably should have been on libc++ maintainers in this case. libc++ almost feels more like a downstream consumer of Clang in terms of testing needs, so I think when tests break because Clang diagnostic wording or behavior changes in a standards conforming way, libc++ folks should address it, but if Clang changes in a way that's not standards conforming, then Clang folks should address it. (Roughly speaking.)

Yes, exactly. It's always possible to write tests that depend on implementation details of another component in subtle ways, and the fact that such brittle tests exist doesn't create a responsibility on that component to avoid breaking those downstream users. Here, it's about Clang making a valid change and libc++ containing brittle tests, but it happens quite often where libc++ changes something valid and a downstream consumer is broken in some way. The LLVM revert culture has some benefits to keep things working in a post-commit CI world, however I've noticed that it also creates a lot of friction between projects and sometimes makes important work much more difficult to land than it should. For example, we're currently in the middle of D128146 where LLDB reverted an important patch for LLVM 15 because one of their tests broke. This is not something that comes up super often, but it's extremely disruptive and frustrating when it does, and I think it would be worth trying to address. Anyway, I'm digressing now, but I'll try to talk to a few people at the LLVM Dev Meeting to see if this is a shared concern and to think about potential solutions to address this.

That said, I absolutely think we all need to continue to collaborate closely with one another as best we can when issues arise, and I really appreciate the discussion on how we can do that!

Agreed.

For this particular issue, I'd like @Codesbyusman to continue to try to fix the libc++ testing issues (it's good experience), but if that takes significantly longer (say, more than 8 hours of his effort), perhaps @ldionne or someone else from libc++ will have a moment to step in to help?

Replacing static_assert by (static_assert|static assertion) should do the trick. See the patch attached to this comment, I think it should satisfy the CI @Codesbyusman.

static_assert.diff70 KBDownload

[erichkeane]

In D129048#3671657, @ldionne wrote:

In D129048#3671568, @aaron.ballman wrote:

FWIW, I've convinced myself that I agree with you here that the burden probably should have been on libc++ maintainers in this case. libc++ almost feels more like a downstream consumer of Clang in terms of testing needs, so I think when tests break because Clang diagnostic wording or behavior changes in a standards conforming way, libc++ folks should address it, but if Clang changes in a way that's not standards conforming, then Clang folks should address it. (Roughly speaking.)

Yes, exactly. It's always possible to write tests that depend on implementation details of another component in subtle ways, and the fact that such brittle tests exist doesn't create a responsibility on that component to avoid breaking those downstream users. Here, it's about Clang making a valid change and libc++ containing brittle tests, but it happens quite often where libc++ changes something valid and a downstream consumer is broken in some way. The LLVM revert culture has some benefits to keep things working in a post-commit CI world, however I've noticed that it also creates a lot of friction between projects and sometimes makes important work much more difficult to land than it should. For example, we're currently in the middle of D128146 where LLDB reverted an important patch for LLVM 15 because one of their tests broke. This is not something that comes up super often, but it's extremely disruptive and frustrating when it does, and I think it would be worth trying to address. Anyway, I'm digressing now, but I'll try to talk to a few people at the LLVM Dev Meeting to see if this is a shared concern and to think about potential solutions to address this.

That said, I absolutely think we all need to continue to collaborate closely with one another as best we can when issues arise, and I really appreciate the discussion on how we can do that!

Agreed.

For this particular issue, I'd like @Codesbyusman to continue to try to fix the libc++ testing issues (it's good experience), but if that takes significantly longer (say, more than 8 hours of his effort), perhaps @ldionne or someone else from libc++ will have a moment to step in to help?

Replacing static_assert by (static_assert|static assertion) should do the trick. See the patch attached to this comment, I think it should satisfy the CI @Codesbyusman.

static_assert.diff70 KBDownload

I just want to say: I really appreciate the insight you gave into the libc++ testing in this thread. From the CFE's perspective, our view of precommit is "it is basically always misconfigured or broken in some way", so knowing that you guys keep yours running well is nice to hear! We'll be more cognizant in the future.

I DO think there IS a sizable difference between patches like this one, and patches like my deferred-concepts (which, btw, the libc++ tests have been great for coming up with new tests... though it was a pain to figure out how to run them in the first place!). My patches DID deserve the reverts it received so far, so don't see Aaron's mention as an issue with that.

I appreciate your suggestion/patch file, that IS a much better regex than we'd come up with, and looks like it should work. So thank you! We'll commit that once @Codesbyusman can get it integrated into his patch (and we'll make sure CI passes too!).

Thanks again Louis!

[Codesbyusman]

In D129048#3671568, @aaron.ballman wrote:

In D129048#3670212, @ldionne wrote:

The libc++ CI runs pre-commit only, and it runs on all commits that touch something under libcxx/, libcxxabi/, runtimes/ and libunwind/. In particular, it won't trigger if you make changes to clang/ only -- that would create too much traffic and concretely it wouldn't help much, as we're rarely broken by Clang changes (this is an exception). Once the tests under libcxx/ were touched, the libc++ CI triggered, I found this build for instance: https://buildkite.com/llvm-project/libcxx-ci/builds/12210. I do think it boils down to familiarity -- while the Clang pre-commit CI is sometimes overlooked because it fails spuriously, the libc++ CI usually doesn't, so when it fails, there's usually a good reason. I do understand why someone mostly familiar with the Clang workflow could think they needed to be overlooked, though.

Thanks for the explanation!

FWIW, the specific reason why I overloooked it was because of running against old versions of Clang -- I saw the diagnostic was correct in the test and presumed that the old clang was a bot configuration issue. It definitely doesn't help that Clang's precommit CI tends to be spuriously broken quite often; it's trained some of us reviewers to be more dismissive of failing precommit CI than we should.

Concretely, libc++ supports the two latest releases of Clang, and so the CI tests against those. In fact, we run most of the tests using pre-installed Clangs since it allows us to bypass building Clang itself, which is a necessary optimization in the current setup. Regarding the tests themselves, I am able to find the following kind of output in the CI job that failed:

Yeah, which makes a lot of sense for libc++!

FAIL: llvm-libc++-shared.cfg.in :: std/numerics/numbers/illformed.verify.cpp (4388 of 7532)
[...]
error: 'error' diagnostics expected but not seen:
  File /home/libcxx-builder/.buildkite-agent/builds/2b1c77dd9e90-1/llvm-project/libcxx-ci/build/generic-cxx2b/include/c++/v1/numbers Line * (directive at /home/libcxx-builder/.buildkite-agent/builds/2b1c77dd9e90-1/llvm-project/libcxx-ci/libcxx/test/std/numerics/numbers/illformed.verify.cpp:15): static assertion failed{{.*}}A program that instantiates a primary template of a mathematical constant variable template is ill-formed.
error: 'error' diagnostics seen but not expected:
  File /home/libcxx-builder/.buildkite-agent/builds/2b1c77dd9e90-1/llvm-project/libcxx-ci/build/generic-cxx2b/include/c++/v1/numbers Line 83: static_assert failed due to requirement '__false<int>' "A program that instantiates a primary template of a mathematical constant variable template is ill-formed."
2 errors generated.

IMO this is reasonable output, in fact it's pretty much as good as we could have had. So I'm not taking any action item regarding improving the output of our CI, but I'm entirely open to suggestions if somebody has some.

I don't have a concrete suggestion for the CI output itself -- the failure was clear in retrospect, this was more a matter of not being familiar with the testing practices used.

In D129048#3669568, @aaron.ballman wrote:

At a high-level, I think it boils down to familiarity. If we can get the libc++ CI to run as part of precommit CI (assuming precommit CI can be made to run with reliable results, which is a bit of a question mark),

It is pretty reliable. However, I don't think it'll ever become reasonable to run the full libc++ CI on every Clang patch due to resource limitations.

The resource limitations are certainly a pragmatic thing for us to be concerned with, but I hope we're able to find some happy middle ground.

It would have also helped to catch the cause for the initial revert where everyone thought the patch was ready to land.

100% agreed, however this is blocked on the resource limitations mentioned above. I guess one thing we could do here is trigger a simple bootstrapping build of Clang and run the libc++ tests in a single configuration even on changes to clang/. That might catch most issues and perhaps that would be small enough to be scalable. I'll experiment with that after the release.

Thanks, that would be really beneficial. It's not just diagnostic wording changes that cause Clang developers problems with libc++ reverts; I've also seen C++20 work reverted because it broke libc++ without anyone in Clang knowing about it until after it landed (most recently, it's with the deferred concept checking work done by @erichkeane).

Another thing that would help would be to get the libc++ test bots into the LLVM lab (https://lab.llvm.org/buildbot/#/builders)

Libc++ CI is pre-commit, the lab is post-commit only AFAICT.

Correct, but right now we have no community testing for libc++ whatsoever from the perspective of Clang folks. We only find out about failures when libc++ folks start reverting or pointing them out.

I also don't know whether there's a way to bridge between BuildKite and BuildBot, and what that would look like. So while I share the desire to have a single place to look for all LLVM wide CI, I'm not sure it is possible given the variety of technologies used.

I don't know enough about the technology to know if it's easy or hard, unfortunately.

and ensure that they're sending failure emails to everyone on the blame list including people who land a patch on behalf of others.

100% agreed here -- this is one problem with our current setup.

It looks like we have one builder for libc++, but it doesn't appear to be working recently: https://lab.llvm.org/buildbot/#/builders/156.

Yeah, this one needs to be removed, it's a remnant of when we used to have libc++ CI on BuildBot.

Okay, so to summarize:

1. I'll experiment with a simple job that runs the libc++ pre-commit CI on every patch to Clang. We'll see if that scales.

Thanks, that would be awesome if it works out!

2. I'll look into sending blame emails from the ongoing (every 3h) job that runs the whole libc++ CI. This is basically equivalent to the buildbot functionality and it's arguably something that we're missing here. I have no idea how to do that, though, but it must be possible.

Thank you!!

3. Usually, for these types of failures, we actually notice and fix it on our end without requesting a revert. For this kind of change, my opinion is that the burden of fixing the code should have been on us, kind of like when the LLDB data formatters break because we made a totally legal change in libc++. Nobody jumped in to fix it on the libc++ side this time because (I assume) we're racing for the release, but normally I or someone else would have chimed in to fix this without annoying Clang.

FWIW, I've convinced myself that I agree with you here that the burden probably should have been on libc++ maintainers in this case. libc++ almost feels more like a downstream consumer of Clang in terms of testing needs, so I think when tests break because Clang diagnostic wording or behavior changes in a standards conforming way, libc++ folks should address it, but if Clang changes in a way that's not standards conforming, then Clang folks should address it. (Roughly speaking.) That said, I absolutely think we all need to continue to collaborate closely with one another as best we can when issues arise, and I really appreciate the discussion on how we can do that!

For this particular issue, I'd like @Codesbyusman to continue to try to fix the libc++ testing issues (it's good experience), but if that takes significantly longer (say, more than 8 hours of his effort), perhaps @ldionne or someone else from libc++ will have a moment to step in to help? (For reference, Usman is a Google Summer of Code mentee and this was his first patch for Clang. I think this has been a really good way for him to see how open source collaborations work in practice but I also don't want him to get bogged down too much if I can help it. Normally I'd step in to help directly, but I've been in WG14 meetings all week and so I am pretty swamped at the moment.)

Yes for me as a complete be beginner was great to see how really open source works. I am working on the libc++ and used regex for the passing of test of previous versions. That is almost complete.

4. That being said, let's try to spread the word that when the libc++ tests do fail on a Clang patch (which implies that libcxx/ will have been touched until (1) is done), they must not be ignored.

Absolutely!

[Codesbyusman]

In D129048#3671665, @erichkeane wrote:

In D129048#3671657, @ldionne wrote:

In D129048#3671568, @aaron.ballman wrote:

FWIW, I've convinced myself that I agree with you here that the burden probably should have been on libc++ maintainers in this case. libc++ almost feels more like a downstream consumer of Clang in terms of testing needs, so I think when tests break because Clang diagnostic wording or behavior changes in a standards conforming way, libc++ folks should address it, but if Clang changes in a way that's not standards conforming, then Clang folks should address it. (Roughly speaking.)

Yes, exactly. It's always possible to write tests that depend on implementation details of another component in subtle ways, and the fact that such brittle tests exist doesn't create a responsibility on that component to avoid breaking those downstream users. Here, it's about Clang making a valid change and libc++ containing brittle tests, but it happens quite often where libc++ changes something valid and a downstream consumer is broken in some way. The LLVM revert culture has some benefits to keep things working in a post-commit CI world, however I've noticed that it also creates a lot of friction between projects and sometimes makes important work much more difficult to land than it should. For example, we're currently in the middle of D128146 where LLDB reverted an important patch for LLVM 15 because one of their tests broke. This is not something that comes up super often, but it's extremely disruptive and frustrating when it does, and I think it would be worth trying to address. Anyway, I'm digressing now, but I'll try to talk to a few people at the LLVM Dev Meeting to see if this is a shared concern and to think about potential solutions to address this.

That said, I absolutely think we all need to continue to collaborate closely with one another as best we can when issues arise, and I really appreciate the discussion on how we can do that!

Agreed.

For this particular issue, I'd like @Codesbyusman to continue to try to fix the libc++ testing issues (it's good experience), but if that takes significantly longer (say, more than 8 hours of his effort), perhaps @ldionne or someone else from libc++ will have a moment to step in to help?

Replacing static_assert by (static_assert|static assertion) should do the trick. See the patch attached to this comment, I think it should satisfy the CI @Codesbyusman.

static_assert.diff70 KBDownload

I just want to say: I really appreciate the insight you gave into the libc++ testing in this thread. From the CFE's perspective, our view of precommit is "it is basically always misconfigured or broken in some way", so knowing that you guys keep yours running well is nice to hear! We'll be more cognizant in the future.

I DO think there IS a sizable difference between patches like this one, and patches like my deferred-concepts (which, btw, the libc++ tests have been great for coming up with new tests... though it was a pain to figure out how to run them in the first place!). My patches DID deserve the reverts it received so far, so don't see Aaron's mention as an issue with that.

I appreciate your suggestion/patch file, that IS a much better regex than we'd come up with, and looks like it should work. So thank you! We'll commit that once @Codesbyusman can get it integrated into his patch (and we'll make sure CI passes too!).

yes will update soon

Thanks again Louis!

[Codesbyusman]

In D129048#3671657, @ldionne wrote:

In D129048#3671568, @aaron.ballman wrote:

FWIW, I've convinced myself that I agree with you here that the burden probably should have been on libc++ maintainers in this case. libc++ almost feels more like a downstream consumer of Clang in terms of testing needs, so I think when tests break because Clang diagnostic wording or behavior changes in a standards conforming way, libc++ folks should address it, but if Clang changes in a way that's not standards conforming, then Clang folks should address it. (Roughly speaking.)

Yes, exactly. It's always possible to write tests that depend on implementation details of another component in subtle ways, and the fact that such brittle tests exist doesn't create a responsibility on that component to avoid breaking those downstream users. Here, it's about Clang making a valid change and libc++ containing brittle tests, but it happens quite often where libc++ changes something valid and a downstream consumer is broken in some way. The LLVM revert culture has some benefits to keep things working in a post-commit CI world, however I've noticed that it also creates a lot of friction between projects and sometimes makes important work much more difficult to land than it should. For example, we're currently in the middle of D128146 where LLDB reverted an important patch for LLVM 15 because one of their tests broke. This is not something that comes up super often, but it's extremely disruptive and frustrating when it does, and I think it would be worth trying to address. Anyway, I'm digressing now, but I'll try to talk to a few people at the LLVM Dev Meeting to see if this is a shared concern and to think about potential solutions to address this.

That said, I absolutely think we all need to continue to collaborate closely with one another as best we can when issues arise, and I really appreciate the discussion on how we can do that!

Agreed.

For this particular issue, I'd like @Codesbyusman to continue to try to fix the libc++ testing issues (it's good experience), but if that takes significantly longer (say, more than 8 hours of his effort), perhaps @ldionne or someone else from libc++ will have a moment to step in to help?

Replacing static_assert by (static_assert|static assertion) should do the trick. See the patch attached to this comment, I think it should satisfy the CI @Codesbyusman.

static_assert.diff70 KBDownload

thanks

[Codesbyusman]

updating of the libcxx with the regex in the diagnostic messages, haven't test them yet locally

[Codesbyusman]

updated libcxx ready to check again

[Codesbyusman]

updated the libcxx all files

[Mordante]

In D129048#3674500, @Codesbyusman wrote:

updated the libcxx all files

FYI for libcxx you can ignore the red format CI step. So the libcxx build is green :-)

I had a look at your libc++ changes and they look good, thanks.
So LGTM for the libc++ part.

[Codesbyusman]

In D129048#3674582, @Mordante wrote:

In D129048#3674500, @Codesbyusman wrote:

updated the libcxx all files

FYI for libcxx you can ignore the red format CI step. So the libcxx build is green :-)

I had a look at your libc++ changes and they look good, thanks.
So LGTM for the libc++ part.

That's great :)

[aaron.ballman]

In D129048#3674585, @Codesbyusman wrote:

In D129048#3674582, @Mordante wrote:

In D129048#3674500, @Codesbyusman wrote:

updated the libcxx all files

FYI for libcxx you can ignore the red format CI step. So the libcxx build is green :-)

I had a look at your libc++ changes and they look good, thanks.
So LGTM for the libc++ part.

That's great :)

Thank you everyone for the great collaboration on this! I just landed the changes and will watch the build bots for any surprise fallout.

[thakis]

This change caused a ton of churn, for what I understand fix the diag in C mode when assert.h is not included.

IMHO, it would've been better to change the diag to say either static_assert as before in c++ mode or when assert.h is included (i.e. almost always), and _Static_assert else. You can use PP.getLastMacroWithSpelling() to (effectively) detect if assert.h was included.

Is this something y'all had considered?

[aaron.ballman]

In D129048#3692394, @thakis wrote:

This change caused a ton of churn, for what I understand fix the diag in C mode when assert.h is not included.

Which is not that uncommon of a scenario: https://sourcegraph.com/search?q=context:global+file:.*%5C.c+_Static_assert&patternType=literal&case=yes

IMHO, it would've been better to change the diag to say either static_assert as before in c++ mode or when assert.h is included (i.e. almost always), and _Static_assert else. You can use PP.getLastMacroWithSpelling() to (effectively) detect if assert.h was included.

Is this something y'all had considered?

Yes, and that approach is actually more complicated to get correct. Part of the trouble is MSVC compatibility where static_assert is allowed in C mode even without including assert.h and that kind of thing. Ultimately, we decided the principle is: if the diagnostic is about parsing the syntax we'll use the actual token name, otherwise we'll use "static assertion" as a prose term instead to avoid having the diagnostic be wrong in edge cases.

clang/include/clang/Basic/DiagnosticSemaKinds.td

def err_messaging_unqualified_id_with_direct_method : Error<
   "messaging unqualified id with a method that is possibly direct">;
 def err_messaging_super_with_direct_method : Error<
   "messaging super with a direct method">;
 def err_messaging_class_with_direct_method : Error<
   "messaging a Class with a method that is possibly direct">;
 
 // C++ declarations
 def err_static_assert_expression_is_not_constant : Error<
-  "static_assert expression is not an integral constant expression">;
+  "static assertion expression is not an integral constant expression">;
 def err_constexpr_if_condition_expression_is_not_constant : Error<
   "constexpr if condition is not a constant expression">;
-def err_static_assert_failed : Error<"static_assert failed%select{: %1|}0">;
+def err_static_assert_failed : Error<"static assertion failed%select{: %1|}0">;
 def err_static_assert_requirement_failed : Error<
-  "static_assert failed due to requirement '%0'%select{: %2|}1">;
+  "static assertion failed due to requirement '%0'%select{: %2|}1">;
 
 def warn_consteval_if_always_true : Warning<
   "consteval if is always true in an %select{unevaluated|immediate}0 context">,
   InGroup<DiagGroup<"redundant-consteval-if">>;
 
 def ext_inline_variable : ExtWarn<
   "inline variables are a C++17 extension">, InGroup<CXX17>;
 def warn_cxx14_compat_inline_variable : Warning<
def err_module_decl_not_at_start : Error<
   "module declaration must occur at the start of the translation unit">;
 def note_global_module_introducer_missing : Note<
   "add 'module;' to the start of the file to introduce a "
   "global module fragment">;
 def err_export_within_anonymous_namespace : Error<
   "export declaration appears within anonymous namespace">;
 def note_anonymous_namespace : Note<"anonymous namespace begins here">;
 def ext_export_no_name_block : ExtWarn<
   "ISO C++20 does not permit %select{an empty|a static_assert}0 declaration "
   "to appear in an export block">, InGroup<ExportUnnamed>;
 def ext_export_no_names : ExtWarn<
   "ISO C++20 does not permit a declaration that does not introduce any names "
   "to be exported">, InGroup<ExportUnnamed>;
 def introduces_no_names : Error<
   "declaration does not introduce any names to be exported">;
 def note_export : Note<"export block begins here">;
 def err_export_no_name : Error<
   "%select{empty|static_assert|asm}0 declaration cannot be exported">;
 def ext_export_using_directive : ExtWarn<
   "ISO C++20 does not permit using directive to be exported">,
   InGroup<DiagGroup<"export-using-directive">>;
 def err_export_within_export : Error<
   "export declaration appears within another export declaration">;
 def err_export_internal : Error<
   "declaration of %0 with internal linkage cannot be exported">;
 def err_export_using_internal : Error<

clang/test/C/drs/dr0xx.c

 _Static_assert(THIS$AND$THAT(1, 1) == 2, "fail"); /* expected-warning 2 {{'$' in identifier}} */
 
 
 /* WG14 DR029: no
  * Do two types have to have the same tag to be compatible?
  * Note: the rule changed in C99 to be different than the resolution to DR029,
  * so it's not clear there's value in implementing this DR.
  */
-_Static_assert(__builtin_types_compatible_p(struct S { int a; }, union U { int a; }), "fail"); /* expected-error {{static_assert failed due to requirement '__builtin_types_compatible_p(struct S, union U)': fail}} */
+_Static_assert(__builtin_types_compatible_p(struct S { int a; }, union U { int a; }), "fail"); /* expected-error {{static assertion failed due to requirement '__builtin_types_compatible_p(struct S, union U)': fail}} */
 
 /* WG14 DR031: yes
  * Can constant expressions overflow?
  */
 void dr031(int i) {
   switch (i) {
   case __INT_MAX__ + 1: break; /* expected-warning {{overflow in expression; result is -2147483648 with type 'int'}} */
   #pragma clang diagnostic push

clang/test/CXX/dcl.dcl/p4-0x.cpp

struct U {
   constexpr operator long() const { return 0; } // expected-note {{candidate}}
 };
 
 static_assert(S(true), "");
 static_assert(S(false), "not so fast"); // expected-error {{not so fast}}
 static_assert(T(), "");
 static_assert(U(), ""); // expected-error {{ambiguous}}
 
-static_assert(false, L"\x14hi" "!" R"x(")x"); // expected-error {{static_assert failed: L"\024hi!\""}}
+static_assert(false, L"\x14hi" "!" R"x(")x"); // expected-error {{static assertion failed: L"\024hi!\""}}

clang/test/CXX/drs/dr19xx.cpp

struct D {
     template<typename T> using D = int; // expected-error {{member 'D' has the same name as its class}} expected-error 0-1{{extension}}
   };
 }
 
 namespace dr1940 { // dr1940: yes
 #if __cplusplus >= 201103L
 static union {
   static_assert(true, "");  // ok
-  static_assert(false, ""); // expected-error {{static_assert failed}}
+  static_assert(false, ""); // expected-error {{static assertion failed}}
   int not_empty;
 };
 #endif
 }
 
 namespace dr1941 { // dr1941: 3.9
 #if __cplusplus >= 201402L
 template<typename X>

clang/test/CXX/expr/expr.prim/expr.prim.id/p3.cpp

 
 // static_assert concept diagnostics
 template<typename T>
 concept Large = sizeof(T) > 100;
 // expected-note@-1 2{{because 'sizeof(small) > 100' (1 > 100) evaluated to false}}
 
 struct small { };
 static_assert(Large<small>);
-// expected-error@-1 {{static_assert failed}}
+// expected-error@-1 {{static assertion failed}}
 // expected-note@-2 {{because 'small' does not satisfy 'Large'}}
 static_assert(Large<small>, "small isn't large");
-// expected-error@-1 {{static_assert failed: small isn't large}}
+// expected-error@-1 {{static assertion failed: small isn't large}}
 // expected-note@-2 {{because 'small' does not satisfy 'Large'}}
 
 // Make sure access-checking can fail a concept specialization
 
 class T4 { static constexpr bool f = true; };
 template<typename T> concept AccessPrivate = T{}.f;
 // expected-note@-1{{because substituted constraint expression is ill-formed: 'f' is a private member of 'T4'}}
 static_assert(AccessPrivate<T4>);
-// expected-error@-1{{static_assert failed}}
+// expected-error@-1{{static assertion failed}}
 // expected-note@-2{{because 'T4' does not satisfy 'AccessPrivate'}}
 
 template<typename T, typename U>
 // expected-note@-1{{template parameter is declared here}}
 concept C8 = sizeof(T) > sizeof(U);
 
 template<typename... T>
 constexpr bool B8 = C8<T...>;

clang/test/CXX/expr/expr.prim/expr.prim.req/nested-requirement.cpp

namespace std_example {
   template<D T> struct D_check {}; // expected-note{{because 'short' does not satisfy 'D'}}
   using dc1 = D_check<short>; // expected-error{{constraints not satisfied for class template 'D_check' [with T = short]}}
 
   template<typename T>
   concept C2 = requires (T a) {
       requires sizeof(a) == 4; // OK
       requires a == 0; // expected-note{{because 'a == 0' would be invalid: constraint variable 'a' cannot be used in an evaluated context}}
     };
-  static_assert(C2<int>); // expected-note{{because 'int' does not satisfy 'C2'}} expected-error{{static_assert failed}}
-}
+  static_assert(C2<int>); // expected-note{{because 'int' does not satisfy 'C2'}} expected-error{{static assertion failed}}
+}
 

clang/test/CXX/temp/temp.constr/temp.constr.constr/partial-specializations.cpp

namespace variable_templates
 
   template<typename T> requires (T{}) // expected-error{{atomic constraint must be of type 'bool' (found 'int')}}
   constexpr bool v1<T**> = true;
 
   static_assert(v1<int**>); // expected-note{{while checking constraint satisfaction for variable template partial specialization 'v1<int *>' required here}}
   // expected-note@-1{{while checking constraint satisfaction for variable template partial specialization 'v1<int>' required here}}
   // expected-note@-2{{during template argument deduction for variable template partial specialization 'v1<T *>' [with T = int *]}}
   // expected-note@-3{{during template argument deduction for variable template partial specialization 'v1<T **>' [with T = int]}}
-  // expected-error@-4{{static_assert failed due to requirement 'v1<int **>'}}
+  // expected-error@-4{{static assertion failed due to requirement 'v1<int **>'}}
 
-}
+}
 

clang/test/PCH/cxx-static_assert.cpp

 #define HEADER
 
 template<int N> struct T {
     static_assert(N == 2, "N is not 2!");
 };
 
 #else
 
-// expected-error@15 {{static_assert failed due to requirement '1 == 2': N is not 2!}}
+// expected-error@15 {{static assertion failed due to requirement '1 == 2': N is not 2!}}
 T<1> t1; // expected-note {{in instantiation of template class 'T<1>' requested here}}
 T<2> t2;
 
 #endif

clang/test/PCH/cxx-templates.cpp

namespace ClassScopeExplicitSpecializations {
   static_assert(A<4>().f<1>() == 1, "");
 }
 
 namespace DependentMemberExpr {
 #ifndef NO_ERRORS
   // This used to mark 'f' invalid without producing any diagnostic. That's a
   // little hard to detect, but we can make sure that constexpr evaluation
   // fails when it should.
-  static_assert(A<int>().f() == 1); // expected-error {{static_assert failed}}
+  static_assert(A<int>().f() == 1); // expected-error {{static assertion failed}}
 #endif
 }
 
 namespace DependentTemplateName {
   struct HasMember {
     template <class T> struct Member;
   };
 

clang/test/Parser/objc-static-assert.m

 
 #if !__has_extension(objc_c_static_assert)
 #error failed
 #endif
 
 @interface A {
   int a;
   _Static_assert(1, "");
-  _Static_assert(0, ""); // expected-error {{static_assert failed}}
+  _Static_assert(0, ""); // expected-error {{static assertion failed}}
 
   _Static_assert(a, ""); // expected-error {{use of undeclared identifier 'a'}}
   _Static_assert(sizeof(a), ""); // expected-error {{use of undeclared identifier 'a'}}
 }
 
 _Static_assert(1, "");
 
 @end

 
 #if !__has_extension(objc_c_static_assert)
 #error failed
 #endif
 
 @interface A {
   int a;
   _Static_assert(1, "");
-  _Static_assert(0, ""); // expected-error {{static_assert failed}}
+  _Static_assert(0, ""); // expected-error {{static assertion failed}}
 }
 
 _Static_assert(1, "");
 
 @end
 
 #endif

clang/test/Parser/objc-static-assert.mm

 
 // C++11
 
 @interface A {
   int a;
   static_assert(1, "");
   _Static_assert(1, "");
 
-  static_assert(0, ""); // expected-error {{static_assert failed}}
-  _Static_assert(0, ""); // expected-error {{static_assert failed}}
+  static_assert(0, ""); // expected-error {{static assertion failed}}
+  _Static_assert(0, ""); // expected-error {{static assertion failed}}
 
-  static_assert(a, ""); // expected-error {{static_assert expression is not an integral constant expression}}
+  static_assert(a, ""); // expected-error {{static assertion expression is not an integral constant expression}}
   static_assert(sizeof(a) == 4, "");
-  static_assert(sizeof(a) == 3, ""); // expected-error {{static_assert failed}}
+  static_assert(sizeof(a) == 3, ""); // expected-error {{static assertion failed}}
 }
 
 static_assert(1, "");
 _Static_assert(1, "");
 
 - (void)f;
 @end
 
 @implementation A {
   int b;
   static_assert(1, "");
   _Static_assert(1, "");
   static_assert(sizeof(b) == 4, "");
-  static_assert(sizeof(b) == 3, ""); // expected-error {{static_assert failed}}
+  static_assert(sizeof(b) == 3, ""); // expected-error {{static assertion failed}}
 }
 
 static_assert(1, "");
 
 - (void)f {
   static_assert(1, "");
 }
 @end
 
 @interface B
 @end
 
 @interface B () {
   int b;
   static_assert(sizeof(b) == 4, "");
-  static_assert(sizeof(b) == 3, ""); // expected-error {{static_assert failed}}
+  static_assert(sizeof(b) == 3, ""); // expected-error {{static assertion failed}}
 }
 @end
 
 #else
 
 #if __has_feature(objc_cxx_static_assert)
 #error failed
 #endif
 
 // C++98
 @interface A {
   int a;
   static_assert(1, ""); // expected-error {{type name requires a specifier or qualifier}} expected-error{{expected parameter declarator}} expected-error {{expected ')'}} expected-note {{to match this '('}}
   _Static_assert(1, "");
-  _Static_assert(0, ""); // expected-error {{static_assert failed}}
+  _Static_assert(0, ""); // expected-error {{static assertion failed}}
 }
 @end
 #endif

clang/test/Sema/builtin-align.c

 // Check that it can be used in constant expressions:
 void constant_expression(int x) {
   _Static_assert(__builtin_is_aligned(1024, 512), "");
   _Static_assert(!__builtin_is_aligned(256, 512ULL), "");
   _Static_assert(__builtin_align_up(33, 32) == 64, "");
   _Static_assert(__builtin_align_down(33, 32) == 32, "");
 
   // But not if one of the arguments isn't constant:
-  _Static_assert(ALIGN_BUILTIN(33, x) != 100, ""); // expected-error {{static_assert expression is not an integral constant expression}}
-  _Static_assert(ALIGN_BUILTIN(x, 4) != 100, "");  // expected-error {{static_assert expression is not an integral constant expression}}
+  _Static_assert(ALIGN_BUILTIN(33, x) != 100, ""); // expected-error {{static assertion expression is not an integral constant expression}}
+  _Static_assert(ALIGN_BUILTIN(x, 4) != 100, "");  // expected-error {{static assertion expression is not an integral constant expression}}
 }
 
 // Check that it is a constant expression that can be assigned to globals:
 int global1 = __builtin_align_down(33, 8);
 int global2 = __builtin_align_up(33, 8);
 _Bool global3 = __builtin_is_aligned(33, 8);
 
 extern void test_ptr(char *c);
 char *test_array_and_fnptr(void) {
   char buf[1024];
   // The builtins should also work on arrays (decaying the return type)
   (void)(ALIGN_BUILTIN(buf, 16));
   // But not on functions and function pointers:
   (void)(ALIGN_BUILTIN(test_array_and_fnptr, 16));  // expected-error{{operand of type 'char *(void)' where arithmetic or pointer type is required}}
   (void)(ALIGN_BUILTIN(&test_array_and_fnptr, 16)); // expected-error{{operand of type 'char *(*)(void)' where arithmetic or pointer type is required}}
 }

clang/test/Sema/sizeless-1.c

void func(int sel) {
   svint8_t __attribute__((aligned(4))) aligned_int8_2; // expected-error {{'aligned' attribute cannot be applied to sizeless type 'svint8_t'}}
   svint8_t _Alignas(int) aligned_int8_3;               // expected-error {{'_Alignas' attribute cannot be applied to sizeless type 'svint8_t'}}
 
   int _Alignas(svint8_t) aligned_int; // expected-error {{invalid application of 'alignof' to sizeless type 'svint8_t'}}
 
   // Using pointers to sizeless data isn't wrong here, but because the
   // type is incomplete, it doesn't provide any alignment guarantees.
   _Static_assert(__atomic_is_lock_free(1, &local_int8) == __atomic_is_lock_free(1, incomplete_ptr), "");
-  _Static_assert(__atomic_is_lock_free(2, &local_int8) == __atomic_is_lock_free(2, incomplete_ptr), ""); // expected-error {{static_assert expression is not an integral constant expression}}
+  _Static_assert(__atomic_is_lock_free(2, &local_int8) == __atomic_is_lock_free(2, incomplete_ptr), ""); // expected-error {{static assertion expression is not an integral constant expression}}
   _Static_assert(__atomic_always_lock_free(1, &local_int8) == __atomic_always_lock_free(1, incomplete_ptr), "");
 
   local_int8; // expected-warning {{expression result unused}}
 
   (void)local_int8;
 
   local_int8, 0; // expected-warning {{left operand of comma operator has no effect}}
 

clang/test/Sema/static-assert.c

 // RUN: %clang_cc1 -std=c11 -fsyntax-only -verify %s
 // RUN: %clang_cc1 -fms-compatibility -DMS -fsyntax-only -verify=expected,ms %s
 // RUN: %clang_cc1 -std=c99 -pedantic -fsyntax-only -verify=expected,ext %s
 // RUN: %clang_cc1 -xc++ -std=c++11 -pedantic -fsyntax-only -verify=expected,ext,cxx %s
 
 _Static_assert("foo", "string is nonzero"); // ext-warning {{'_Static_assert' is a C11 extension}}
 #ifndef __cplusplus
-// expected-error@-2 {{static_assert expression is not an integral constant expression}}
+// expected-error@-2 {{static assertion expression is not an integral constant expression}}
 #endif
 
 _Static_assert(1, "1 is nonzero"); // ext-warning {{'_Static_assert' is a C11 extension}}
-_Static_assert(0, "0 is nonzero"); // expected-error {{static_assert failed: 0 is nonzero}} \
+_Static_assert(0, "0 is nonzero"); // expected-error {{static assertion failed: 0 is nonzero}} \
                                    // ext-warning {{'_Static_assert' is a C11 extension}}
 
 #ifdef MS
 static_assert(1, "1 is nonzero"); // ms-warning {{use of 'static_assert' without inclusion of <assert.h> is a Microsoft extension}}
 #endif
 
 void foo(void) {
   _Static_assert(1, "1 is nonzero"); // ext-warning {{'_Static_assert' is a C11 extension}}
-  _Static_assert(0, "0 is nonzero"); // expected-error {{static_assert failed: 0 is nonzero}} \
+  _Static_assert(0, "0 is nonzero"); // expected-error {{static assertion failed: 0 is nonzero}} \
                                      // ext-warning {{'_Static_assert' is a C11 extension}}
 #ifdef MS
   static_assert(1, "1 is nonzero"); // ms-warning {{use of 'static_assert' without}}
 #endif
 }
 
 _Static_assert(1, invalid); // expected-error {{expected string literal for diagnostic message in static_assert}} \
                             // ext-warning {{'_Static_assert' is a C11 extension}}
 
 struct A {
   int a;
   _Static_assert(1, "1 is nonzero"); // ext-warning {{'_Static_assert' is a C11 extension}}
-  _Static_assert(0, "0 is nonzero"); // expected-error {{static_assert failed: 0 is nonzero}} \
+  _Static_assert(0, "0 is nonzero"); // expected-error {{static assertion failed: 0 is nonzero}} \
                                      // ext-warning {{'_Static_assert' is a C11 extension}}
 #ifdef MS
   static_assert(1, "1 is nonzero"); // ms-warning {{use of 'static_assert' without}}
 #endif
 };
 
 #ifdef __cplusplus
 #define ASSERT_IS_TYPE(T) __is_same(T, T)
 #else
 #define ASSERT_IS_TYPE(T) __builtin_types_compatible_p(T, T)
 #endif
 
 #define UNION(T1, T2) union { \
     __typeof__(T1) one; \
     __typeof__(T2) two; \
     _Static_assert(ASSERT_IS_TYPE(T1), "T1 is not a type"); \
     _Static_assert(ASSERT_IS_TYPE(T2), "T2 is not a type"); \
     _Static_assert(sizeof(T1) == sizeof(T2), "type size mismatch"); \
   }
 
 typedef UNION(unsigned, struct A) U1; // ext-warning 3 {{'_Static_assert' is a C11 extension}}
 UNION(char[2], short) u2 = { .one = { 'a', 'b' } }; // ext-warning 3 {{'_Static_assert' is a C11 extension}} cxx-warning {{designated initializers are a C++20 extension}}
-typedef UNION(char, short) U3; // expected-error {{static_assert failed due to requirement 'sizeof(char) == sizeof(short)': type size mismatch}} \
+typedef UNION(char, short) U3; // expected-error {{static assertion failed due to requirement 'sizeof(char) == sizeof(short)': type size mismatch}} \
                                // ext-warning 3 {{'_Static_assert' is a C11 extension}}
 typedef UNION(float, 0.5f) U4; // expected-error {{expected a type}} \
                                // ext-warning 3 {{'_Static_assert' is a C11 extension}}
 
 // After defining the assert macro in MS-compatibility mode, we should
 // no longer warn about including <assert.h> under the assumption the
 // user already did that.
 #ifdef MS
 #define assert(expr)
 static_assert(1, "1 is nonzero"); // ok
 
 // But we should still warn if the user did something bonkers.
 #undef static_assert
 static_assert(1, "1 is nonzero"); // ms-warning {{use of 'static_assert' without}}
 #endif

clang/test/SemaCXX/access-base-class.cpp

 template <class T>
 class b {
   a<T> x;
   using U = a<T>;
 };
 
 template <int>
 struct Impossible {
-  static_assert(false, ""); // expected-error {{static_assert failed}}
+  static_assert(false, ""); // expected-error {{static assertion failed}}
 };
 
 // verify "no member named 'value'" bogus diagnostic is not emitted.
 trait<b<Impossible<0>>>::value;
 } // namespace T8

clang/test/SemaCXX/alias-template.cpp

 namespace PR24212 {
 struct X {};
 template <int I>
 struct S {
   template <int J>
   using T = X[J];
   using U = T<I>;
 };
-static_assert(__is_same(S<3>::U, X[2]), ""); // expected-error {{static_assert failed}}
+static_assert(__is_same(S<3>::U, X[2]), ""); // expected-error {{static assertion failed}}
 }
 
 namespace PR39623 {
 template <class T>
 using void_t = void;
 
 template <class T, class = void_t<typename T::wait_what>>
 int sfinae_me() { return 0; } // expected-note{{candidate template ignored: substitution failure}}
 
 int g = sfinae_me<int>(); // expected-error{{no matching function for call to 'sfinae_me'}}
 }
 
 namespace NullExceptionDecl {
 template<int... I> auto get = []() { try { } catch(...) {}; return I; }; // expected-error{{initializer contains unexpanded parameter pack 'I'}}
 }

clang/test/SemaCXX/builtin-is-constant-evaluated.cpp

 const int n = __builtin_is_constant_evaluated() ? 4 : dummy;
 static_assert(n == 4);
 constexpr int cn = __builtin_is_constant_evaluated() ? 11 : dummy;
 static_assert(cn == 11);
 // expected-error@+1 {{'bn' must be initialized by a constant expression}}
 constexpr int bn = __builtin_is_constant_evaluated() ? dummy : 42; // expected-note {{non-const variable 'dummy' is not allowed}}
 
 const int n2 = __builtin_is_constant_evaluated() ? dummy : 42; // expected-note {{declared here}}
-static_assert(n2 == 42);                                       // expected-error {{static_assert expression is not an integral constant}}
+static_assert(n2 == 42);                                       // expected-error {{static assertion expression is not an integral constant}}
 // expected-note@-1 {{initializer of 'n2' is not a constant expression}}
 
 template <bool V, bool Default = std::is_constant_evaluated()>
 struct Templ { static_assert(V); static_assert(Default); };
 Templ<__builtin_is_constant_evaluated()> x; // type X<true>
 
 template <class T>
 void test_if_constexpr() {

clang/test/SemaCXX/builtin-std-move.cpp

#endif
   template<typename T> struct is_lvalue_reference<T&> { static constexpr bool value = true; };
 
   template<typename T> CONSTEXPR T &&forward(typename remove_reference<T>::type &x) {
     static_assert(T::moveable, "instantiated forward"); // expected-error {{no member named 'moveable' in 'B'}}
                                                         // expected-error@-1 {{no member named 'moveable' in 'C'}}
     return static_cast<T&&>(x);
   }
   template<typename T> CONSTEXPR T &&forward(typename remove_reference<T>::type &&x) {
-    static_assert(!is_lvalue_reference<T>::value, "should not forward rval as lval"); // expected-error {{static_assert failed}}
+    static_assert(!is_lvalue_reference<T>::value, "should not forward rval as lval"); // expected-error {{static assertion failed}}
     return static_cast<T&&>(x);
   }
 
   template<typename T> CONSTEXPR const T &as_const(T &x) {
     static_assert(T::moveable, "instantiated as_const"); // expected-error {{no member named 'moveable' in 'B'}}
     return x;
   }
 

clang/test/SemaCXX/builtins.cpp

namespace addressof {
 
   S *ptmp = __builtin_addressof(S{}); // expected-error {{taking the address of a temporary}}
 }
 
 namespace function_start {
 void a(void) {}
 int n;
 void *p = __builtin_function_start(n);               // expected-error {{argument must be a function}}
-static_assert(__builtin_function_start(a) == a, ""); // expected-error {{static_assert expression is not an integral constant expression}}
+static_assert(__builtin_function_start(a) == a, ""); // expected-error {{static assertion expression is not an integral constant expression}}
 } // namespace function_start
 
 void no_ms_builtins() {
   __assume(1); // expected-error {{use of undeclared}}
   __noop(1); // expected-error {{use of undeclared}}
   __debugbreak(); // expected-error {{use of undeclared}}
 }
 

clang/test/SemaCXX/complex-folding.cpp

 // RUN: %clang_cc1 %s -std=c++1z -fsyntax-only -verify
 //
 // Test the constant folding of builtin complex numbers.
 
 static_assert((0.0 + 0.0j) == (0.0 + 0.0j));
-static_assert((0.0 + 0.0j) != (0.0 + 0.0j)); // expected-error {{static_assert}}
+static_assert((0.0 + 0.0j) != (0.0 + 0.0j)); // expected-error {{static assertion}}
 
 static_assert((0.0 + 0.0j) == 0.0);
 static_assert(0.0 == (0.0 + 0.0j));
 static_assert(0.0 == 0.0j);
 static_assert((0.0 + 1.0j) != 0.0);
 static_assert(1.0 != (0.0 + 0.0j));
 static_assert(0.0 != 1.0j);
 
 // Walk around the complex plane stepping between angular differences and
 // equality.
-static_assert((1.0 + 0.0j) == (0.0 + 0.0j)); // expected-error {{static_assert}}
+static_assert((1.0 + 0.0j) == (0.0 + 0.0j)); // expected-error {{static assertion}}
 static_assert((1.0 + 0.0j) == (1.0 + 0.0j));
-static_assert((1.0 + 1.0j) == (1.0 + 0.0j)); // expected-error {{static_assert}}
+static_assert((1.0 + 1.0j) == (1.0 + 0.0j)); // expected-error {{static assertion}}
 static_assert((1.0 + 1.0j) == (1.0 + 1.0j));
-static_assert((0.0 + 1.0j) == (1.0 + 1.0j)); // expected-error {{static_assert}}
+static_assert((0.0 + 1.0j) == (1.0 + 1.0j)); // expected-error {{static assertion}}
 static_assert((0.0 + 1.0j) == (0.0 + 1.0j));
-static_assert((-1.0 + 1.0j) == (0.0 + 1.0j)); // expected-error {{static_assert}}
+static_assert((-1.0 + 1.0j) == (0.0 + 1.0j)); // expected-error {{static assertion}}
 static_assert((-1.0 + 1.0j) == (-1.0 + 1.0j));
-static_assert((-1.0 + 0.0j) == (-1.0 + 1.0j)); // expected-error {{static_assert}}
+static_assert((-1.0 + 0.0j) == (-1.0 + 1.0j)); // expected-error {{static assertion}}
 static_assert((-1.0 + 0.0j) == (-1.0 + 0.0j));
-static_assert((-1.0 - 1.0j) == (-1.0 + 0.0j)); // expected-error {{static_assert}}
+static_assert((-1.0 - 1.0j) == (-1.0 + 0.0j)); // expected-error {{static assertion}}
 static_assert((-1.0 - 1.0j) == (-1.0 - 1.0j));
-static_assert((0.0 - 1.0j) == (-1.0 - 1.0j)); // expected-error {{static_assert}}
+static_assert((0.0 - 1.0j) == (-1.0 - 1.0j)); // expected-error {{static assertion}}
 static_assert((0.0 - 1.0j) == (0.0 - 1.0j));
-static_assert((1.0 - 1.0j) == (0.0 - 1.0j)); // expected-error {{static_assert}}
+static_assert((1.0 - 1.0j) == (0.0 - 1.0j)); // expected-error {{static assertion}}
 static_assert((1.0 - 1.0j) == (1.0 - 1.0j));
 
 // Test basic mathematical folding of both complex and real operands.
 static_assert(((1.0 + 0.5j) + (0.25 - 0.75j)) == (1.25 - 0.25j));
 static_assert(((1.0 + 0.5j) + 0.25) == (1.25 + 0.5j));
 static_assert((1.0 + (0.25 - 0.75j)) == (1.25 - 0.75j));
 
 static_assert(((1.0 + 0.5j) - (0.25 - 0.75j)) == (0.75 + 1.25j));

clang/test/SemaCXX/constant-expression-cxx11.cpp

 constexpr int err_zs_1_2_0_0 = zs[1][2][0][0]; // \
 expected-error {{constant expression}} \
 expected-note {{cannot access array element of pointer past the end}}
 
 constexpr int fail(const int &p) {
   return (&p)[64]; // expected-note {{cannot refer to element 64 of array of 2 elements}}
 }
 static_assert(fail(*(&(&(*(*&(&zs[2] - 1)[0] + 2 - 2))[2])[-1][2] - 2)) == 11, ""); // \
-expected-error {{static_assert expression is not an integral constant expression}} \
+expected-error {{static assertion expression is not an integral constant expression}} \
 expected-note {{in call to 'fail(zs[1][0][1][0])'}}
 
 constexpr int arr[40] = { 1, 2, 3, [8] = 4 };
 constexpr int SumNonzero(const int *p) {
   return *p + (*p ? SumNonzero(p+1) : 0);
 }
 constexpr int CountZero(const int *p, const int *q) {
   return p == q ? 0 : (*p == 0) + CountZero(p+1, q);
constexpr int n = 1 +
         * 3;
   }
 }
 
 namespace CompoundLiteral {
   // Matching GCC, file-scope array compound literals initialized by constants
   // are lifetime-extended.
   constexpr int *p = (int*)(int[1]){3}; // expected-warning {{C99}}
-  static_assert(*p == 3, "");           // expected-error {{static_assert expression is not an integral constant expression}}
+  static_assert(*p == 3, "");           // expected-error {{static assertion expression is not an integral constant expression}}
                                         // expected-note@-1 {{subexpression not valid}}
                                         // expected-note@-3 {{declared here}}
   static_assert((int[2]){1, 2}[1] == 2, ""); // expected-warning {{C99}}
-  // expected-error@-1 {{static_assert expression is not an integral constant expression}}
+  // expected-error@-1 {{static assertion expression is not an integral constant expression}}
   // expected-note@-2 {{subexpression not valid}}
   // expected-note@-3 {{declared here}}
 
   // Other kinds are not.
   struct X { int a[2]; };
   constexpr int *n = (X){1, 2}.a; // expected-warning {{C99}} expected-warning {{temporary}}
   // expected-error@-1 {{constant expression}}
   // expected-note@-2 {{pointer to subobject of temporary}}
namespace VirtualFromBase {
   };
 
   // Virtual f(), not OK.
   constexpr X<X<S1>> xxs1;
   constexpr X<S1> *p = const_cast<X<X<S1>>*>(&xxs1);
   static_assert(p->f() == sizeof(X<S1>), "");
   // cxx11-error@-1    {{not an integral constant expression}}
   // cxx11-note@-2     {{call to virtual function}}
-  // cxx20_2b-error@-3 {{static_assert failed}}
+  // cxx20_2b-error@-3 {{static assertion failed}}
 
   // Non-virtual f(), OK.
   constexpr X<X<S2>> xxs2;
   constexpr X<S2> *q = const_cast<X<X<S2>>*>(&xxs2);
-  static_assert(q->f() == sizeof(S2), ""); // cxx20_2b-error {{static_assert failed}}
+  static_assert(q->f() == sizeof(S2), ""); // cxx20_2b-error {{static assertion failed}}
 }
 
 namespace ConstexprConstructorRecovery {
   class X {
   public:
       enum E : short {
           headers = 0x1,
           middlefile = 0x2,

clang/test/SemaCXX/constexpr-builtin-bit-cast.cpp

constexpr bool f(bool read_uninit) {
 
   if (read_uninit && b.d[10]) // expected-note{{read of uninitialized object is not allowed in a constant expression}}
     return false;
 
   return true;
 }
 
 static_assert(f(/*read_uninit=*/false), "");
-static_assert(f(/*read_uninit=*/true), ""); // expected-error{{static_assert expression is not an integral constant expression}} expected-note{{in call to 'f(true)'}}
+static_assert(f(/*read_uninit=*/true), ""); // expected-error{{static assertion expression is not an integral constant expression}} expected-note{{in call to 'f(true)'}}
 
 constexpr bytes ld539 = {
   0x0, 0x0,  0x0,  0x0,
   0x0, 0x0,  0xc0, 0x86,
   0x8, 0x40, 0x0,  0x0,
   0x0, 0x0,  0x0,  0x0,
 };
 
 constexpr long double fivehundredandthirtynine = 539.0;
 
 static_assert(bit_cast<long double>(ld539) == fivehundredandthirtynine, "");
 
 #else
 static_assert(round_trip<__int128_t>(34.0L));
 #endif
 }

clang/test/SemaCXX/constexpr-function-recovery-crash.cpp

 template<int x> constexpr int f(int y) { // expected-note {{candidate template ignored}}
   return x * y;
 }
 constexpr int test9(int x) {
   return f<1>(f<x>(1)); // expected-error {{no matching function for call to 'f'}}
 }
 
 constexpr int test10() { return undef(); } // expected-error {{use of undeclared identifier 'undef'}}
-static_assert(test10() <= 1, "should not crash"); // expected-error {{static_assert expression is not an integral constant expression}}
+static_assert(test10() <= 1, "should not crash"); // expected-error {{static assertion expression is not an integral constant expression}}
 
 struct X {} array[] = {undef()}; // expected-error {{use of undeclared identifier 'undef'}}
 constexpr void test11() {
   for (X& e : array) {}
 }
 
 constexpr int test12() { return "wrong"; } // expected-error {{cannot initialize return object of type 'int'}}
 constexpr int force12 = test12();          // expected-error {{must be initialized by a constant}}

clang/test/SemaCXX/coroutines-exp-namespace.cpp

CoroMemberTag test_qual() {
     auto TC = co_yield 0;
     static_assert(TC.MatchesArgs<TestType &>, "");
     static_assert(!TC.MatchesArgs<TestType>, "");
     static_assert(!TC.MatchesArgs<TestType *>, "");
   }
 
   CoroMemberTag test_asserts(int *) const {
     auto TC = co_yield 0;
-    static_assert(TC.MatchesArgs<const TestType &>, ""); // expected-error {{static_assert failed}}
-    static_assert(TC.MatchesArgs<const TestType &>, ""); // expected-error {{static_assert failed}}
+    static_assert(TC.MatchesArgs<const TestType &>, ""); // expected-error {{static assertion failed}}
+    static_assert(TC.MatchesArgs<const TestType &>, ""); // expected-error {{static assertion failed}}
     static_assert(TC.MatchesArgs<const TestType &, int *>, "");
   }
 
   CoroMemberTag test_qual(int *, const float &&, volatile void *volatile) const {
     // cxx20_2b-warning@-1 {{volatile-qualified parameter type}}
     auto TC = co_yield 0;
     static_assert(TC.MatchesArgs<const TestType &, int *, const float &&, volatile void *volatile>, "");
   }

 template CoroMemberTag TestType::test_member_template(long, const char *) const &&;
 template CoroMemberTag TestType::test_static_template<void>(const char *volatile &, unsigned);
 
 template <class... Args>
 struct DepTestType {
 
   CoroMemberTag test_asserts(int *) const {
     auto TC = co_yield 0;
-    static_assert(TC.template MatchesArgs<const DepTestType &>, ""); // expected-error {{static_assert failed}}
-    static_assert(TC.template MatchesArgs<>, "");                    // expected-error {{static_assert failed}}
+    static_assert(TC.template MatchesArgs<const DepTestType &>, ""); // expected-error {{static assertion failed}}
+    static_assert(TC.template MatchesArgs<>, "");                    // expected-error {{static assertion failed}}
     static_assert(TC.template MatchesArgs<const DepTestType &, int *>, "");
   }
 
   CoroMemberTag test_qual() {
     auto TC = co_yield 0;
     static_assert(TC.template MatchesArgs<DepTestType &>, "");
     static_assert(!TC.template MatchesArgs<DepTestType>, "");
     static_assert(!TC.template MatchesArgs<DepTestType *>, "");
static CoroMemberTag test_static() {
     auto TC = co_yield 0;
     using TCT = decltype(TC);
     static_assert(TCT::MatchesArgs<>, "");
     static_assert(!TCT::MatchesArgs<DepTestType>, "");
     static_assert(!TCT::MatchesArgs<DepTestType &>, "");
     static_assert(!TCT::MatchesArgs<DepTestType *>, "");
 
     // Ensure diagnostics are actually being generated here
-    static_assert(TCT::MatchesArgs<int>, ""); // expected-error {{static_assert failed}}
+    static_assert(TCT::MatchesArgs<int>, ""); // expected-error {{static assertion failed}}
   }
 
   static CoroMemberTag test_static(volatile void *const, char &&) {
     auto TC = co_yield 0;
     using TCT = decltype(TC);
     static_assert(TCT::MatchesArgs<volatile void *const, char &&>, "");
   }
 

clang/test/SemaCXX/coroutines.cpp

CoroMemberTag test_qual() {
     auto TC = co_yield 0;
     static_assert(TC.MatchesArgs<TestType &>, "");
     static_assert(!TC.MatchesArgs<TestType>, "");
     static_assert(!TC.MatchesArgs<TestType *>, "");
   }
 
   CoroMemberTag test_asserts(int *) const {
     auto TC = co_yield 0;
-    static_assert(TC.MatchesArgs<const TestType &>, ""); // expected-error {{static_assert failed}}
-    static_assert(TC.MatchesArgs<const TestType &>, ""); // expected-error {{static_assert failed}}
+    static_assert(TC.MatchesArgs<const TestType &>, ""); // expected-error {{static assertion failed}}
+    static_assert(TC.MatchesArgs<const TestType &>, ""); // expected-error {{static assertion failed}}
     static_assert(TC.MatchesArgs<const TestType &, int *>, "");
   }
 
   CoroMemberTag test_qual(int *, const float &&, volatile void *volatile) const {
     // cxx20_2b-warning@-1 {{volatile-qualified parameter type}}
     auto TC = co_yield 0;
     static_assert(TC.MatchesArgs<const TestType &, int *, const float &&, volatile void *volatile>, "");
   }

 template CoroMemberTag TestType::test_member_template(long, const char *) const &&;
 template CoroMemberTag TestType::test_static_template<void>(const char *volatile &, unsigned);
 
 template <class... Args>
 struct DepTestType {
 
   CoroMemberTag test_asserts(int *) const {
     auto TC = co_yield 0;
-    static_assert(TC.template MatchesArgs<const DepTestType &>, ""); // expected-error {{static_assert failed}}
-    static_assert(TC.template MatchesArgs<>, ""); // expected-error {{static_assert failed}}
+    static_assert(TC.template MatchesArgs<const DepTestType &>, ""); // expected-error {{static assertion failed}}
+    static_assert(TC.template MatchesArgs<>, ""); // expected-error {{static assertion failed}}
     static_assert(TC.template MatchesArgs<const DepTestType &, int *>, "");
   }
 
   CoroMemberTag test_qual() {
     auto TC = co_yield 0;
     static_assert(TC.template MatchesArgs<DepTestType &>, "");
     static_assert(!TC.template MatchesArgs<DepTestType>, "");
     static_assert(!TC.template MatchesArgs<DepTestType *>, "");
static CoroMemberTag test_static() {
     auto TC = co_yield 0;
     using TCT = decltype(TC);
     static_assert(TCT::MatchesArgs<>, "");
     static_assert(!TCT::MatchesArgs<DepTestType>, "");
     static_assert(!TCT::MatchesArgs<DepTestType &>, "");
     static_assert(!TCT::MatchesArgs<DepTestType *>, "");
 
     // Ensure diagnostics are actually being generated here
-    static_assert(TCT::MatchesArgs<int>, ""); // expected-error {{static_assert failed}}
+    static_assert(TCT::MatchesArgs<int>, ""); // expected-error {{static assertion failed}}
   }
 
   static CoroMemberTag test_static(volatile void *const, char &&) {
     auto TC = co_yield 0;
     using TCT = decltype(TC);
     static_assert(TCT::MatchesArgs<volatile void *const, char &&>, "");
   }
 

clang/test/SemaCXX/cxx2a-template-lambdas.cpp

 // RUN: %clang_cc1 -std=c++2a -verify %s
 
 template<typename, typename>
 constexpr bool is_same = false;
 
 template<typename T>
 constexpr bool is_same<T, T> = true;
 
 template<typename T>
 struct DummyTemplate { };
 
 void func() {
   auto L0 = []<typename T>(T arg) {
-    static_assert(is_same<T, int>); // expected-error {{static_assert failed}}
+    static_assert(is_same<T, int>); // expected-error {{static assertion failed}}
   };
   L0(0);
   L0(0.0); // expected-note {{in instantiation}}
 
   auto L1 = []<int I> {
-    static_assert(I == 5); // expected-error {{static_assert failed}}
+    static_assert(I == 5); // expected-error {{static assertion failed}}
   };
   L1.operator()<5>();
   L1.operator()<6>(); // expected-note {{in instantiation}}
 
   auto L2 = []<template<typename> class T, class U>(T<U> &&arg) {
-    static_assert(is_same<T<U>, DummyTemplate<float>>); // // expected-error {{static_assert failed}}
+    static_assert(is_same<T<U>, DummyTemplate<float>>); // // expected-error {{static assertion failed}}
   };
   L2(DummyTemplate<float>());
   L2(DummyTemplate<double>()); // expected-note {{in instantiation}}
 }
 
 template<typename T> // expected-note {{declared here}}
 struct ShadowMe {
   void member_func() {

clang/test/SemaCXX/delete-and-function-templates.cpp

 // RUN: %clang_cc1 -std=c++11 -verify -fsyntax-only  -emit-llvm-only %s
 // RUN: %clang_cc1 -std=c++11 -verify -fsyntax-only  -fdelayed-template-parsing %s 
 // RUN: %clang_cc1 -std=c++11 -verify -fsyntax-only  -fms-extensions %s 
 // RUN: %clang_cc1 -std=c++11 -verify -fsyntax-only  -fdelayed-template-parsing -fms-extensions %s 
 
 template<class T, class U> struct is_same { enum { value = false }; };
 template<class T> struct is_same<T, T> { enum { value = true }; };
 
 namespace test_sfinae_and_delete {
 
 namespace ns1 {
 template<class T> double f(T) = delete; //expected-note{{candidate}}
 char f(...); //expected-note{{candidate}}
 
-static_assert(is_same<decltype(f(3)),char>::value, ""); //expected-error{{call to deleted function}} expected-error{{static_assert failed}}
+static_assert(is_same<decltype(f(3)),char>::value, ""); //expected-error{{call to deleted function}} expected-error{{static assertion failed}}
 
 template<class T> decltype(f(T{})) g(T); // this one sfinae's out.
 template<class T> int *g(T);
 void foo() {
   int *ip = g(3);
 }
 } //end ns1
 

clang/test/SemaCXX/int-ptr-cast-SFINAE.cpp

 
 template<typename T>
 typename select<(sizeof(declval<T>() -= declval<T>(), 1) != 1), true_type, false_type>::type test(...);
 template<typename T> false_type test(...);
 
 template<typename T>
 static const auto has_minus_assign = decltype(test<T>())::value;
 
-static_assert(has_minus_assign<int*>, "failed"); // expected-error {{static_assert failed due to requirement 'has_minus_assign<int *>': failed}}
+static_assert(has_minus_assign<int*>, "failed"); // expected-error {{static assertion failed due to requirement 'has_minus_assign<int *>': failed}}

clang/test/SemaCXX/recovery-expr-type.cpp

 void crash2() { constexpr int s = fun(); }
 } // namespace test12
 
 namespace test13 {
 enum Circular {             // expected-note {{not complete until the closing '}'}}
   Circular_A = Circular(1), // expected-error {{'test13::Circular' is an incomplete type}}
 };
 // Enumerators can be evaluated (they evaluate as zero, but we don't care).
-static_assert(Circular_A == 0 && Circular_A != 0, ""); // expected-error {{static_assert failed}}
+static_assert(Circular_A == 0 && Circular_A != 0, ""); // expected-error {{static assertion failed}}
 }
 
 namespace test14 {
 extern "C" void *memset(void *, int b, unsigned long) {
   int * const c(undef()); // expected-error {{undeclared identifier}}
   // Verify we do not crash on evaluating *c whose initializer is a NULL-type ParenListExpr!
   memset(c, 0, *c); // crash1
 
   b = __builtin_object_size(c, 0); // crash2
 }
 }

clang/test/SemaCXX/sizeless-1.cpp

void func(int sel) {
   svint8_t __attribute__((aligned(4))) aligned_int8_2; // expected-error {{'aligned' attribute cannot be applied to sizeless type 'svint8_t'}}
   svint8_t _Alignas(int) aligned_int8_3;               // expected-error {{'_Alignas' attribute cannot be applied to sizeless type 'svint8_t'}}
 
   int _Alignas(svint8_t) aligned_int; // expected-error {{invalid application of 'alignof' to sizeless type 'svint8_t'}}
 
   // Using pointers to sizeless data isn't wrong here, but because the
   // type is incomplete, it doesn't provide any alignment guarantees.
   _Static_assert(__atomic_is_lock_free(1, &local_int8) == __atomic_is_lock_free(1, incomplete_ptr), "");
-  _Static_assert(__atomic_is_lock_free(2, &local_int8) == __atomic_is_lock_free(2, incomplete_ptr), ""); // expected-error {{static_assert expression is not an integral constant expression}}
+  _Static_assert(__atomic_is_lock_free(2, &local_int8) == __atomic_is_lock_free(2, incomplete_ptr), ""); // expected-error {{static assertion expression is not an integral constant expression}}
   _Static_assert(__atomic_always_lock_free(1, &local_int8) == __atomic_always_lock_free(1, incomplete_ptr), "");
 
   local_int8; // expected-warning {{expression result unused}}
 
   (void)local_int8;
 
   local_int8, 0; // expected-warning {{left operand of comma operator has no effect}}
 

clang/test/SemaCXX/static-assert-cxx17.cpp

 template <typename U, typename V>
 inline constexpr bool constexpr_return_false() {
   return false;
 }
 
 template <typename U, typename V>
 void foo() {
   static_assert(S1<U, V>::value);
-  // expected-error@-1{{static_assert failed due to requirement 'S1<int, float>::value'}}
+  // expected-error@-1{{static assertion failed due to requirement 'S1<int, float>::value'}}
 }
 template void foo<int, float>();
 // expected-note@-1{{in instantiation of function template specialization 'foo<int, float>' requested here}}
 
 template <typename U, typename V>
 void foo2() {
   static_assert(global_inline_var<U, V>);
-  // expected-error@-1{{static_assert failed due to requirement 'global_inline_var<int, float>'}}
+  // expected-error@-1{{static assertion failed due to requirement 'global_inline_var<int, float>'}}
 }
 template void foo2<int, float>();
 // expected-note@-1{{in instantiation of function template specialization 'foo2<int, float>' requested here}}
 
 template <typename T, typename U, typename V>
 void foo3() {
   static_assert(T::template var<U, V>);
-  // expected-error@-1{{static_assert failed due to requirement 'S2<long>::var<int, float>'}}
+  // expected-error@-1{{static assertion failed due to requirement 'S2<long>::var<int, float>'}}
 }
 template void foo3<S2<long>, int, float>();
 // expected-note@-1{{in instantiation of function template specialization 'foo3<S2<long>, int, float>' requested here}}
 
 template <typename T>
 void foo4() {
   static_assert(S1<T[sizeof(T)], int[4]>::value, "");
-  // expected-error@-1{{static_assert failed due to requirement 'S1<float[4], int[4]>::value'}}
+  // expected-error@-1{{static assertion failed due to requirement 'S1<float[4], int[4]>::value'}}
 };
 template void foo4<float>();
 // expected-note@-1{{in instantiation of function template specialization 'foo4<float>' requested here}}
 
 
 template <typename U, typename V>
 void foo5() {
   static_assert(!!(global_inline_var<U, V>));
-  // expected-error@-1{{static_assert failed due to requirement '!!(global_inline_var<int, float>)'}}
+  // expected-error@-1{{static assertion failed due to requirement '!!(global_inline_var<int, float>)'}}
 }
 template void foo5<int, float>();
 // expected-note@-1{{in instantiation of function template specialization 'foo5<int, float>' requested here}}
 
 struct ExampleTypes {
   explicit ExampleTypes(int);
   using T = int;
   using U = float;
 };
 
 template <class T>
 struct X {
   int i = 0;
   int j = 0;
   constexpr operator bool() const { return false; }
 };
 
 template <class T>
 void foo6() {
   static_assert(X<typename T::T>());
-  // expected-error@-1{{static_assert failed due to requirement 'X<int>()'}}
+  // expected-error@-1{{static assertion failed due to requirement 'X<int>()'}}
   static_assert(X<typename T::T>{});
-  // expected-error@-1{{static_assert failed due to requirement 'X<int>{}'}}
+  // expected-error@-1{{static assertion failed due to requirement 'X<int>{}'}}
   static_assert(X<typename T::T>{1, 2});
-  // expected-error@-1{{static_assert failed due to requirement 'X<int>{1, 2}'}}
+  // expected-error@-1{{static assertion failed due to requirement 'X<int>{1, 2}'}}
   static_assert(X<typename T::T>({1, 2}));
-  // expected-error@-1{{static_assert failed due to requirement 'X<int>({1, 2})'}}
+  // expected-error@-1{{static assertion failed due to requirement 'X<int>({1, 2})'}}
   static_assert(typename T::T{0});
-  // expected-error@-1{{static_assert failed due to requirement 'int{0}'}}
+  // expected-error@-1{{static assertion failed due to requirement 'int{0}'}}
   static_assert(typename T::T(0));
-  // expected-error@-1{{static_assert failed due to requirement 'int(0)'}}
+  // expected-error@-1{{static assertion failed due to requirement 'int(0)'}}
   static_assert(sizeof(X<typename T::T>) == 0);
-  // expected-error@-1{{static_assert failed due to requirement 'sizeof(X<int>) == 0'}}
+  // expected-error@-1{{static assertion failed due to requirement 'sizeof(X<int>) == 0'}}
   static_assert((const X<typename T::T> *)nullptr);
-  // expected-error@-1{{static_assert failed due to requirement '(const X<int> *)nullptr'}}
+  // expected-error@-1{{static assertion failed due to requirement '(const X<int> *)nullptr'}}
   static_assert(static_cast<const X<typename T::T> *>(nullptr));
-  // expected-error@-1{{static_assert failed due to requirement 'static_cast<const X<int> *>(nullptr)'}}
+  // expected-error@-1{{static assertion failed due to requirement 'static_cast<const X<int> *>(nullptr)'}}
   static_assert((const X<typename T::T>[]){} == nullptr);
-  // expected-error@-1{{static_assert failed due to requirement '(const X<int>[0]){} == nullptr'}}
+  // expected-error@-1{{static assertion failed due to requirement '(const X<int>[0]){} == nullptr'}}
   static_assert(sizeof(X<decltype(X<typename T::T>().X<typename T::T>::~X())>) == 0);
-  // expected-error@-1{{static_assert failed due to requirement 'sizeof(X<void>) == 0'}}
+  // expected-error@-1{{static assertion failed due to requirement 'sizeof(X<void>) == 0'}}
   static_assert(constexpr_return_false<typename T::T, typename T::U>());
-  // expected-error@-1{{static_assert failed due to requirement 'constexpr_return_false<int, float>()'}}
+  // expected-error@-1{{static assertion failed due to requirement 'constexpr_return_false<int, float>()'}}
 }
 template void foo6<ExampleTypes>();
 // expected-note@-1{{in instantiation of function template specialization 'foo6<ExampleTypes>' requested here}}

clang/test/SemaCXX/static-assert.cpp

 // RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11 -pedantic -triple=x86_64-linux-gnu
 
 int f(); // expected-note {{declared here}}
 
-static_assert(f(), "f"); // expected-error {{static_assert expression is not an integral constant expression}} expected-note {{non-constexpr function 'f' cannot be used in a constant expression}}
+static_assert(f(), "f"); // expected-error {{static assertion expression is not an integral constant expression}} expected-note {{non-constexpr function 'f' cannot be used in a constant expression}}
 static_assert(true, "true is not false");
-static_assert(false, "false is false"); // expected-error {{static_assert failed: false is false}}
+static_assert(false, "false is false"); // expected-error {{static assertion failed: false is false}}
 
 void g() {
-    static_assert(false, "false is false"); // expected-error {{static_assert failed: false is false}}
+    static_assert(false, "false is false"); // expected-error {{static assertion failed: false is false}}
 }
 
 class C {
-    static_assert(false, "false is false"); // expected-error {{static_assert failed: false is false}}
+    static_assert(false, "false is false"); // expected-error {{static assertion failed: false is false}}
 };
 
 template<int N> struct T {
-    static_assert(N == 2, "N is not 2!"); // expected-error {{static_assert failed due to requirement '1 == 2': N is not 2!}}
+    static_assert(N == 2, "N is not 2!"); // expected-error {{static assertion failed due to requirement '1 == 2': N is not 2!}}
 };
 
 T<1> t1; // expected-note {{in instantiation of template class 'T<1>' requested here}}
 T<2> t2;
 
 template<typename T> struct S {
-    static_assert(sizeof(T) > sizeof(char), "Type not big enough!"); // expected-error {{static_assert failed due to requirement 'sizeof(char) > sizeof(char)': Type not big enough!}}
+    static_assert(sizeof(T) > sizeof(char), "Type not big enough!"); // expected-error {{static assertion failed due to requirement 'sizeof(char) > sizeof(char)': Type not big enough!}}
 };
 
 S<char> s1; // expected-note {{in instantiation of template class 'S<char>' requested here}}
 S<int> s2;
 
-static_assert(false, L"\xFFFFFFFF"); // expected-error {{static_assert failed: L"\xFFFFFFFF"}}
-static_assert(false, u"\U000317FF"); // expected-error {{static_assert failed: u"\U000317FF"}}
+static_assert(false, L"\xFFFFFFFF"); // expected-error {{static assertion failed: L"\xFFFFFFFF"}}
+static_assert(false, u"\U000317FF"); // expected-error {{static assertion failed: u"\U000317FF"}}
 
-static_assert(false, u8"Ω"); // expected-error {{static_assert failed: u8"\316\251"}}
-static_assert(false, L"\u1234"); // expected-error {{static_assert failed: L"\x1234"}}
-static_assert(false, L"\x1ff" "0\x123" "fx\xfffff" "goop"); // expected-error {{static_assert failed: L"\x1FF""0\x123""fx\xFFFFFgoop"}}
+static_assert(false, u8"Ω"); // expected-error {{static assertion failed: u8"\316\251"}}
+static_assert(false, L"\u1234"); // expected-error {{static assertion failed: L"\x1234"}}
+static_assert(false, L"\x1ff" "0\x123" "fx\xfffff" "goop"); // expected-error {{static assertion failed: L"\x1FF""0\x123""fx\xFFFFFgoop"}}
 
 static_assert(false, R"(a
 \tb
 c
-)"); // expected-error@-3 {{static_assert failed: a\n\tb\nc\n}}
+)"); // expected-error@-3 {{static assertion failed: a\n\tb\nc\n}}
 
 static_assert(false, "\u0080\u0081\u0082\u0083\u0099\u009A\u009B\u009C\u009D\u009E\u009F");
-// expected-error@-1 {{static_assert failed: <U+0080><U+0081><U+0082><U+0083><U+0099><U+009A><U+009B><U+009C><U+009D><U+009E><U+009F>}}
+// expected-error@-1 {{static assertion failed: <U+0080><U+0081><U+0082><U+0083><U+0099><U+009A><U+009B><U+009C><U+009D><U+009E><U+009F>}}
 
 //! Contains RTL/LTR marks
-static_assert(false, "\u200Eabc\u200Fdef\u200Fgh"); // expected-error {{static_assert failed: ‎abc‏def‏gh}}
+static_assert(false, "\u200Eabc\u200Fdef\u200Fgh"); // expected-error {{static assertion failed: ‎abc‏def‏gh}}
 
 //! Contains ZWJ/regional indicators
-static_assert(false, "🏳️‍🌈 🏴󠁧󠁢󠁥󠁮󠁧󠁿 🇪🇺"); // expected-error {{static_assert failed: 🏳️‍🌈 🏴󠁧󠁢󠁥󠁮󠁧󠁿 🇪🇺}}
+static_assert(false, "🏳️‍🌈 🏴󠁧󠁢󠁥󠁮󠁧󠁿 🇪🇺"); // expected-error {{static assertion failed: 🏳️‍🌈 🏴󠁧󠁢󠁥󠁮󠁧󠁿 🇪🇺}}
 
 template<typename T> struct AlwaysFails {
   // Only give one error here.
-  static_assert(false, ""); // expected-error {{static_assert failed}}
+  static_assert(false, ""); // expected-error {{static assertion failed}}
 };
 AlwaysFails<int> alwaysFails;
 
 template<typename T> struct StaticAssertProtected {
-  static_assert(__is_literal(T), ""); // expected-error {{static_assert failed}}
+  static_assert(__is_literal(T), ""); // expected-error {{static assertion failed}}
   static constexpr T t = {}; // no error here
 };
 struct X { ~X(); };
 StaticAssertProtected<int> sap1;
 StaticAssertProtected<X> sap2; // expected-note {{instantiation}}
 
 static_assert(true); // expected-warning {{C++17 extension}}
 static_assert(false); // expected-error-re {{failed{{$}}}} expected-warning {{extension}}
 
 
 // Diagnostics for static_assert with multiple conditions
 template<typename T> struct first_trait {
   static const bool value = false;
 };
 
 template<>
 struct first_trait<X> {
   static const bool value = true;
 };
 
 template<typename T> struct second_trait {
   static const bool value = false;
 };
 
-static_assert(first_trait<X>::value && second_trait<X>::value, "message"); // expected-error{{static_assert failed due to requirement 'second_trait<X>::value': message}}
+static_assert(first_trait<X>::value && second_trait<X>::value, "message"); // expected-error{{static assertion failed due to requirement 'second_trait<X>::value': message}}
 
 namespace std {
 
 template <class Tp, Tp v>
 struct integral_constant {
   static const Tp value = v;
   typedef Tp value_type;
   typedef integral_constant type;

 
 struct ExampleTypes {
   explicit ExampleTypes(int);
   using T = int;
   using U = float;
 };
 
 static_assert(std::is_same<ExampleTypes::T, ExampleTypes::U>::value, "message");
-// expected-error@-1{{static_assert failed due to requirement 'std::is_same<int, float>::value': message}}
+// expected-error@-1{{static assertion failed due to requirement 'std::is_same<int, float>::value': message}}
 static_assert(std::is_const<ExampleTypes::T>::value, "message");
-// expected-error@-1{{static_assert failed due to requirement 'std::is_const<int>::value': message}}
+// expected-error@-1{{static assertion failed due to requirement 'std::is_const<int>::value': message}}
 static_assert(!std::is_const<const ExampleTypes::T>::value, "message");
-// expected-error@-1{{static_assert failed due to requirement '!std::is_const<const int>::value': message}}
+// expected-error@-1{{static assertion failed due to requirement '!std::is_const<const int>::value': message}}
 static_assert(!(std::is_const<const ExampleTypes::T>::value), "message");
-// expected-error@-1{{static_assert failed due to requirement '!(std::is_const<const int>::value)': message}}
+// expected-error@-1{{static assertion failed due to requirement '!(std::is_const<const int>::value)': message}}
 static_assert(std::is_const<const ExampleTypes::T>::value == false, "message");
-// expected-error@-1{{static_assert failed due to requirement 'std::is_const<const int>::value == false': message}}
+// expected-error@-1{{static assertion failed due to requirement 'std::is_const<const int>::value == false': message}}
 static_assert(!(std::is_const<const ExampleTypes::T>::value == true), "message");
-// expected-error@-1{{static_assert failed due to requirement '!(std::is_const<const int>::value == true)': message}}
+// expected-error@-1{{static assertion failed due to requirement '!(std::is_const<const int>::value == true)': message}}
 static_assert(std::is_const<ExampleTypes::T>(), "message");
-// expected-error@-1{{static_assert failed due to requirement 'std::is_const<int>()': message}}
+// expected-error@-1{{static assertion failed due to requirement 'std::is_const<int>()': message}}
 static_assert(!(std::is_const<const ExampleTypes::T>()()), "message");
-// expected-error@-1{{static_assert failed due to requirement '!(std::is_const<const int>()())': message}}
+// expected-error@-1{{static assertion failed due to requirement '!(std::is_const<const int>()())': message}}
 static_assert(std::is_same<decltype(std::is_const<const ExampleTypes::T>()), int>::value, "message");
-// expected-error@-1{{static_assert failed due to requirement 'std::is_same<std::is_const<const int>, int>::value': message}}
+// expected-error@-1{{static assertion failed due to requirement 'std::is_same<std::is_const<const int>, int>::value': message}}
 static_assert(std::is_const<decltype(ExampleTypes::T(3))>::value, "message");
-// expected-error@-1{{static_assert failed due to requirement 'std::is_const<int>::value': message}}
+// expected-error@-1{{static assertion failed due to requirement 'std::is_const<int>::value': message}}
 static_assert(std::is_const<decltype(ExampleTypes::T())>::value, "message");
-// expected-error@-1{{static_assert failed due to requirement 'std::is_const<int>::value': message}}
+// expected-error@-1{{static assertion failed due to requirement 'std::is_const<int>::value': message}}
 static_assert(std::is_const<decltype(ExampleTypes(3))>::value, "message");
-// expected-error@-1{{static_assert failed due to requirement 'std::is_const<ExampleTypes>::value': message}}
+// expected-error@-1{{static assertion failed due to requirement 'std::is_const<ExampleTypes>::value': message}}
 
 struct BI_tag {};
 struct RAI_tag : BI_tag {};
 struct MyIterator {
   using tag = BI_tag;
 };
 struct MyContainer {
   using iterator = MyIterator;
 };
 template <class Container>
 void foo() {
   static_assert(std::is_same<RAI_tag, typename Container::iterator::tag>::value, "message");
-  // expected-error@-1{{static_assert failed due to requirement 'std::is_same<RAI_tag, BI_tag>::value': message}}
+  // expected-error@-1{{static assertion failed due to requirement 'std::is_same<RAI_tag, BI_tag>::value': message}}
 }
 template void foo<MyContainer>();
 // expected-note@-1{{in instantiation of function template specialization 'foo<MyContainer>' requested here}}
 
 namespace ns {
 template <typename T, int v>
 struct NestedTemplates1 {
   struct NestedTemplates2 {
     template <typename U>
     struct NestedTemplates3 : public std::is_same<T, U> {};
   };
 };
 } // namespace ns
 
 template <typename T, typename U, int a>
 void foo2() {
   static_assert(::ns::NestedTemplates1<T, a>::NestedTemplates2::template NestedTemplates3<U>::value, "message");
-  // expected-error@-1{{static_assert failed due to requirement '::ns::NestedTemplates1<int, 3>::NestedTemplates2::NestedTemplates3<float>::value': message}}
+  // expected-error@-1{{static assertion failed due to requirement '::ns::NestedTemplates1<int, 3>::NestedTemplates2::NestedTemplates3<float>::value': message}}
 }
 template void foo2<int, float, 3>();
 // expected-note@-1{{in instantiation of function template specialization 'foo2<int, float, 3>' requested here}}
 
 template <class T>
 void foo3(T t) {
   static_assert(std::is_const<T>::value, "message");
-  // expected-error-re@-1{{static_assert failed due to requirement 'std::is_const<(lambda at {{.*}}static-assert.cpp:{{[0-9]*}}:{{[0-9]*}})>::value': message}}
+  // expected-error-re@-1{{static assertion failed due to requirement 'std::is_const<(lambda at {{.*}}static-assert.cpp:{{[0-9]*}}:{{[0-9]*}})>::value': message}}
   static_assert(std::is_const<decltype(t)>::value, "message");
-  // expected-error-re@-1{{static_assert failed due to requirement 'std::is_const<(lambda at {{.*}}static-assert.cpp:{{[0-9]*}}:{{[0-9]*}})>::value': message}}
+  // expected-error-re@-1{{static assertion failed due to requirement 'std::is_const<(lambda at {{.*}}static-assert.cpp:{{[0-9]*}}:{{[0-9]*}})>::value': message}}
 }
 void callFoo3() {
   foo3([]() {});
   // expected-note@-1{{in instantiation of function template specialization 'foo3<(lambda at }}
 }
 
 template <class T>
 void foo4(T t) {
   static_assert(std::is_const<typename T::iterator>::value, "message");
   // expected-error@-1{{type 'int' cannot be used prior to '::' because it has no members}}
 }
 void callFoo4() { foo4(42); }
 // expected-note@-1{{in instantiation of function template specialization 'foo4<int>' requested here}}
 
 static_assert(42, "message");
 static_assert(42.0, "message"); // expected-warning {{implicit conversion from 'double' to 'bool' changes value from 42 to true}}
 constexpr int *p = 0;
-static_assert(p, "message"); // expected-error {{static_assert failed}}
+static_assert(p, "message"); // expected-error {{static assertion failed}}
 
 struct NotBool {
 } notBool;
 constexpr NotBool constexprNotBool;
 static_assert(notBool, "message");          // expected-error {{value of type 'struct NotBool' is not contextually convertible to 'bool'}}
 static_assert(constexprNotBool, "message"); // expected-error {{value of type 'const NotBool' is not contextually convertible to 'bool'}}

clang/test/SemaCXX/using-decl-templates.cpp

namespace aliastemplateinst {
   template<typename T> struct A { };
   template<typename T> using APtr = A<T*>; // expected-note{{previous use is here}}
 
   template struct APtr<int>; // expected-error{{type alias template 'APtr' cannot be referenced with a struct specifier}}
 }
 
 namespace DontDiagnoseInvalidTest {
 template <bool Value> struct Base {
-  static_assert(Value, ""); // expected-error {{static_assert failed}}
+  static_assert(Value, ""); // expected-error {{static assertion failed}}
 };
 struct Derived : Base<false> { // expected-note {{requested here}}
   using Base<false>::Base; // OK. Don't diagnose that 'Base' isn't a base class of Derived.
 };
 } // namespace DontDiagnoseInvalidTest
 
 namespace func_templ {
 namespace sss {

clang/test/SemaCXX/weak-init.cpp

 // RUN: %clang_cc1 %s -verify -fsyntax-only
 
 extern const int W1 __attribute__((weak)) = 10; // expected-note {{declared here}}
 
-static_assert(W1 == 10, ""); // expected-error   {{static_assert expression is not an integral constant expression}}
+static_assert(W1 == 10, ""); // expected-error   {{static assertion expression is not an integral constant expression}}
                              // expected-note@-1 {{initializer of weak variable 'W1' is not considered constant because it may be different at runtime}}
 
 extern const int W2 __attribute__((weak)) = 20;
 
 int S2[W2]; // expected-error {{variable length array declaration not allowed at file scope}}
 
 extern const int W3 __attribute__((weak)) = 30; // expected-note {{declared here}}
 
 constexpr int S3 = W3; // expected-error   {{constexpr variable 'S3' must be initialized by a constant expression}}
                        // expected-note@-1 {{initializer of weak variable 'W3' is not considered constant because it may be different at runtime}}

clang/test/SemaTemplate/instantiate-var-template.cpp

namespace InstantiationDependent {
 
   template<int> constexpr int a = 1;
   template<typename T> constexpr T b = a<sizeof(sizeof(f(T())))>; // expected-error {{invalid application of 'sizeof' to an incomplete type 'void'}}
 
   static_assert(b<int> == 1, "");
   static_assert(b<char> == 1, ""); // expected-note {{in instantiation of}} expected-error {{not an integral constant}}
 
   template<typename T> void f() {
-    static_assert(a<sizeof(sizeof(f(T())))> == 0, ""); // expected-error {{static_assert failed due to requirement 'a<sizeof (sizeof (f(type-parameter-0-0())))> == 0'}}
+    static_assert(a<sizeof(sizeof(f(T())))> == 0, ""); // expected-error {{static assertion failed due to requirement 'a<sizeof (sizeof (f(type-parameter-0-0())))> == 0'}}
   }
 }
 
 namespace PR24483 {
   template<typename> struct A;
   template<typename... T> A<T...> models;
   template<> struct B models<>; // expected-error {{incomplete type 'struct B'}} expected-note {{forward declaration}}
 }
 
 namespace InvalidInsertPos {
   template<typename T, int N> T v;
   template<int N> decltype(v<int, N-1>) v<int, N>;
   template<> int v<int, 0>;
   int k = v<int, 500>;
 }

clang/test/SemaTemplate/pr52909.cpp

 };
 
 template <class T>
 concept Beginable = requires (T t) {
   { t.begin } -> C;
   // expected-note@-1 {{because 't.begin' would be invalid: reference to non-static member function must be called}}
 };
 
-static_assert(Beginable<A>); // expected-error {{static_assert failed}}
+static_assert(Beginable<A>); // expected-error {{static assertion failed}}
                              // expected-note@-1 {{does not satisfy 'Beginable'}}
 } // namespace PR52905
 
 namespace PR52909a {
 
 template<class> constexpr bool B = true;
 template<class T> concept True = B<T>;
 
template<class T> concept C = requires {
     { T::begin } -> True; // expected-note {{because 'T::begin' would be invalid: reference to overloaded function could not be resolved}}
 };
 
 struct A {
     static void begin(int);
     static void begin(double);
 };
 
-static_assert(C<A>); // expected-error {{static_assert failed}}
+static_assert(C<A>); // expected-error {{static assertion failed}}
   // expected-note@-1 {{because 'PR52909b::A' does not satisfy 'C'}}
 
 } // namespace PR52909b
 
 namespace PR53075 {
 template<class> concept True = true;
 
 template<class T> concept C = requires {
     { &T::f } -> True; // expected-note {{because '&T::f' would be invalid: reference to overloaded function could not be resolved}}
 };
 
 struct S {
     int *f();
     int *f() const;
 };
 
-static_assert(C<S>); // expected-error {{static_assert failed}}
+static_assert(C<S>); // expected-error {{static assertion failed}}
   // expected-note@-1 {{because 'PR53075::S' does not satisfy 'C'}}
 
 } // namespace PR53075

clang/test/SemaTemplate/pr52970.cpp

 
 #if __cplusplus >= 202002L
 template <class T>
 concept C = requires(T t) { t.a.b; };
   // cxx20-note@-1 {{because 't.a.b' would be invalid: reference to non-static member function must be called}}
 
 static_assert(C<Good>);
 static_assert(!C<Bad>);
-static_assert(C<Bad>); // cxx20-error {{static_assert failed}}
+static_assert(C<Bad>); // cxx20-error {{static assertion failed}}
   // cxx20-note@-1 {{because 'DotFollowingFunctionName::Bad' does not satisfy 'C'}}
 #endif
 } // namespace DotFollowingFunctionName
 
 namespace DotFollowingPointer {
 struct Good {
   int begin();
 };
 using Bad = Holder<Incomplete> *;
 
 template <class T>
 constexpr auto f(T t) -> decltype((t.begin(), true)) { return true; }
 constexpr bool f(...) { return false; }
 
 static_assert(DotFollowingPointer::f(Good{}), "");
 static_assert(!DotFollowingPointer::f(Bad{}), "");
 
 #if __cplusplus >= 202002L
 template <class T>
 concept C = requires(T t) { t.begin(); };
   // cxx20-note@-1 {{because 't.begin()' would be invalid: member reference type 'Holder<Incomplete> *' is a pointer}}
 
 static_assert(C<Good>);
 static_assert(!C<Bad>);
-static_assert(C<Bad>); // cxx20-error {{static_assert failed}}
+static_assert(C<Bad>); // cxx20-error {{static assertion failed}}
   // cxx20-note@-1 {{because 'DotFollowingPointer::Bad' (aka 'Holder<Incomplete> *') does not satisfy 'C'}}
 #endif
 } // namespace DotFollowingPointer

clang/test/SemaTemplate/temp_arg_nontype_cxx20.cpp

namespace TemplateSpecializations {
   Z<A{1, 2}, A{1, 2, 0}> z1;
   Z<A{1, 2}, A{1, 3}> z2; // expected-error {{undefined}}
 
   template struct Z<A{1}, A{1, 0}>;
 }
 
 namespace Diags {
   struct A { int n, m; };
-  template<A a> struct X { static_assert(a.n == a.m); }; // expected-error {{static_assert failed due to requirement 'Diags::A{1, 2}.n == Diags::A{1, 2}.m'}}
+  template<A a> struct X { static_assert(a.n == a.m); }; // expected-error {{static assertion failed due to requirement 'Diags::A{1, 2}.n == Diags::A{1, 2}.m'}}
   template struct X<A{1, 2}>; // expected-note {{in instantiation of template class 'Diags::X<{1, 2}>' requested here}}
 }
 
 namespace CTADPartialOrder {
   template<int> struct A {};
   template<typename T, typename U, A a> struct X; // expected-note {{declared here}}
   template<typename T, A a> struct X<T, int, a> { static constexpr int n = 1; }; // expected-note {{matches}}
   template<typename T, A a> struct X<T *, int, a> { static constexpr int n = 2; };