C23 makes assert into a variadic macro to handle cases of an argument
that would be interpreted as a single function argument but more than
one macro argument (in particular, compound literals with an
unparenthesized comma in an initializer list); this change was made by
N2829.  Note that this only applies to assert, not to other macros
specified in the C standard with particular numbers of arguments.

Implement this support in glibc.  This change is only for C; C++ would
need a separate change to its separate assert implementations.  It's
also applied only in C23 mode.  It depends on support for (C99)
variadic macros, and also (in order to detect calls where more than
one expression is passed, via an unevaluated function call) a C99
boolean type.  These requirements are encapsulated in the definition
of __ASSERT_VARIADIC.  Tests with -std=c99 and -std=gnu99 (using
implementations continue to work.

I don't think we have a way in the glibc testsuite to validate that
passing more than one expression as an argument does produce the
desired error.

Tested for x86_64.

This helps compilers split the codegen for setting up the arguments
(`__expression`, `__filename`, etc...) from the potentially hot cold
where the `assert` is to a presumably cold region on the assertion
failure path.

Reviewed-by: Florian Weimer <fweimer@redhat.com>
Reviewed-by: Sam James <sam@gentoo.org>

Likewise use __builtin_LINE instead of __LINE__.

When building C++, inline functions are required to have the exact same
sequence of tokens in every translation unit. But __FILE__ token, when
used in a header file, does not necessarily expand to the exact same
string literal, and that may cause compilation failure when C++ modules
are being used. (It would also cause unpredictable output on assertion
failure at runtime, but this rarely matters in practice.)

For example, given the following sources:

  // a.h
  #include <assert.h>
  inline void fn () { assert (0); }

  // a.cc
  #include "a.h"

  // b.cc
  #include "foo/../a.h"

preprocessing a.cc will yield a call to __assert_fail("0", "a.h", ...)
but b.cc will yield __assert_fail("0", "foo/../a.h", ...)

C2x makes static_assert and thread_local into keywords, removing the
definitions as macros in assert.h and threads.h.  Thus, disable those
macros in those glibc headers for C2x.

The disabling is done based on a combination of language version and
__GNUC_PREREQ, *not* based on __GLIBC_USE (ISOC2X), on the principle
that users of the header (when requesting C11 or later APIs - not
assert.h for C99 and older API versions) should always have the names
static_assert or thread_local available after inclusion of the header,
whether as a keyword or as a macro.  Thus, when using a compiler
without the keywords (whether an older compiler, possibly in C2x mode,
or _GNU_SOURCE with any compiler but in an older language mode, for
example) the macros should be defined, even when C2x APIs have been
requested.  The __GNUC_PREREQ conditionals here may well need updating
with the versions of other compilers that gained support for these
keywords in C2x mode.

Tested for x86_64.

I used these shell commands:

../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright
(cd ../glibc && git commit -am"[this commit message]")

and then ignored the output, which consisted lines saying "FOO: warning:
copyright statement not found" for each of 7061 files FOO.

I then removed trailing white space from math/tgmath.h,
support/tst-support-open-dev-null-range.c, and
sysdeps/x86_64/multiarch/strlen-vec.S, to work around the following
obscure pre-commit check failure diagnostics from Savannah.  I don't
know why I run into these diagnostics whereas others evidently do not.

remote: *** 912-#endif
remote: *** 913:
remote: *** 914-
remote: *** error: lines with trailing whitespace found
...
remote: *** error: sysdeps/unix/sysv/linux/statx_cp.c: trailing lines

I used these shell commands:

../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright
(cd ../glibc && git commit -am"[this commit message]")

and then ignored the output, which consisted lines saying "FOO: warning:
copyright statement not found" for each of 6694 files FOO.
I then removed trailing white space from benchtests/bench-pthread-locks.c
and iconvdata/tst-iconv-big5-hkscs-to-2ucs4.c, to work around this
diagnostic from Savannah:
remote: *** pre-commit check failed ...
remote: *** error: lines with trailing whitespace found
remote: error: hook declined to update refs/heads/master