The following patch uses make_signed_t<size_t> instead of
make_signed<size_t>::type in the diagnostics, because the former is shorter.
It is true that one can't use make_signed<size_t>::type in C++11 code (which
is why I haven't changed it in the testcase which is c++11 effective
target), but the message talks about C++23 and make_signed_t is a C++14 and
later feature, so I think it is fine.

2021-02-04  Jakub Jelinek  <jakub@redhat.com>

	* expr.c (cpp_classify_number): Use make_signed_t<size_t> instead of
	make_signed<size_t>::type in the diagnostics.

	* g++.dg/warn/Wsize_t-literals.C: Expect make_signed_t<size_t> instead
	of make_signed<size_t>::type in the diagnostics.

Integer literal suffixes for signed size ('z') and unsigned size
(some permutation od 'zu') are provided as a language addition.

gcc/c-family/ChangeLog:

	* c-cppbuiltin.c (c_cpp_builtins): Define __cpp_size_t_suffix.
	* c-lex.c (interpret_integer): Set node type for size literal.

libcpp/ChangeLog:

	* expr.c (interpret_int_suffix): Detect 'z' integer suffix.
	(cpp_classify_number): Compat warning for use of 'z' suffix.
	* include/cpplib.h (struct cpp_options): New flag.
	(enum cpp_warning_reason): New flag.
	(CPP_N_USERDEF): Comment C++0x -> C++11.
	(CPP_N_SIZE_T): New flag for cpp_classify_number.
	* init.c (cpp_set_lang): Initialize new flag.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/udlit-shadow-neg.C: Test for 'z' and 'zu' shadowing.
	* g++.dg/cpp23/feat-cxx2b.C: New test.
	* g++.dg/cpp23/size_t-literals.C: New test.
	* g++.dg/warn/Wsize_t-literals.C: New test.

Deferred macros are needed for C++ modules.  Header units may export
macro definitions and undefinitions.  These are resolved lazily at the
point of (potential) use.  (The language specifies that, it's not just
a useful optimization.)  Thus, identifier nodes grow a 'deferred'
field, which fortunately doesn't expand the structure on 64-bit
systems as there was padding there.  This is non-zero on NT_MACRO
nodes, if the macro is deferred.  When such an identifier is lexed, it
is resolved via a callback that I added recently.  That will either
provide the macro definition, or discover it there was an overriding
undef.  Either way the identifier is no longer a deferred macro.
Notice it is now possible for NT_MACRO nodes to have a NULL macro
expansion.

	libcpp/
	* include/cpplib.h (struct cpp_hashnode): Add deferred field.
	(cpp_set_deferred_macro): Define.
	(cpp_get_deferred_macro): Declare.
	(cpp_macro_definition): Reformat, add overload.
	(cpp_macro_definition_location): Deal with deferred macro.
	(cpp_alloc_token_string, cpp_compare_macro): Declare.
	* internal.h (_cpp_notify_macro_use): Return bool
	(_cpp_maybe_notify_macro_use): Likewise.
	* directives.c (do_undef): Check macro is not undef before
	warning.
	(do_ifdef, do_ifndef): Deal with deferred macro.
	* expr.c (parse_defined): Likewise.
	* lex.c (cpp_allocate_token_string): Break out of ...
	(create_literal): ... here.  Call it.
	(cpp_maybe_module_directive): Deal with deferred macro.
	* macro.c (cpp_get_token_1): Deal with deferred macro.
	(warn_of_redefinition): Deal with deferred macro.
	(compare_macros): Rename to ...
	(cpp_compare_macro): ... here.  Make extern.
	(cpp_get_deferred_macro): New.
	(_cpp_notify_macro_use): Deal with deferred macro, return bool
	indicating definedness.
	(cpp_macro_definition): Deal with deferred macro.

C2x adds binary integer constants (approved at the last WG14 meeting,
though not yet added to the working draft in git).  Configure libcpp
to consider these a standard feature in C2x mode, with appropriate
updates to diagnostics including support for diagnosing them with
-std=c2x -Wc11-c2x-compat.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

gcc/testsuite/
2020-11-13  Joseph Myers  <joseph@codesourcery.com>

	* gcc.dg/binary-constants-2.c, gcc.dg/binary-constants-3.c,
	gcc.dg/system-binary-constants-1.c: Update expected diagnostics.
	* gcc.dg/c11-binary-constants-1.c,
	gcc.dg/c11-binary-constants-2.c, gcc.dg/c2x-binary-constants-1.c,
	gcc.dg/c2x-binary-constants-2.c, gcc.dg/c2x-binary-constants-3.c:
	New tests.

libcpp/
2020-11-13  Joseph Myers  <joseph@codesourcery.com>

	* expr.c (cpp_classify_number): Update diagnostic for binary
	constants for C.  Also diagnose binary constants for
	-Wc11-c2x-compat.
	* init.c (lang_defaults): Enable binary constants for GNUC2X and
	STDC2X.

Our macro use hook passes a location, but doesn't recieve it from the
using location.  This patch adds the extra location_t parameter and
passes it though.

A second cleanup is breaking out the macro comparison code from the
redefinition warning.  That;ll turn out useful for modules.

Finally, there's a filename comparison needed for the location
optimization of rewinding from line 2 (occurs during the emission of
builtin macros).

	libcpp/
	* internal.h (_cpp_notify_macro_use): Add location parm.
	(_cpp_maybe_notify_macro_use): Likewise.
	* directives.c (_cpp_do_file_change): Check we've not changed file
	when optimizing a rewind.
	(do_ifdef): Pass location to _cpp_maybe_notify_macro_use.
	(do_ifndef): Likewise.  Delete obsolete comment about powerpc.
	* expr.c (parse_defined): Pass location to
	_cpp_maybe_notify_macro_use.
	* macro.c (enter_macro_context): Likewise.
	(warn_of_redefinition): Break out helper function.  Call it.
	(compare_macros): New function broken out of warn_of_redefinition.
	(_cpp_new_macro): Zero all fields.
	(_cpp_notify_macro_use): Add location parameter.

The clever hack of '#define __has_include __has_include' breaks -dD
and -fdirectives-only, because that emits definitions.  This turns
__has_include into a proper builtin macro.  Thus it's never emitted
via -dD, and because use outside of directive processing is undefined,
we can just expand it anywhere.

	PR preprocessor/93452
	* internal.h (struct spec_nodes): Drop n__has_include{,_next}.
	* directives.c (lex_macro_node): Don't check __has_include redef.
	* expr.c (eval_token): Drop __has_include eval.
	(parse_has_include): Move to ...
	* macro.c (builtin_has_include): ... here.
	(_cpp_builtin_macro_text): Eval __has_include{,_next}.
	* include/cpplib.h (enum cpp_builtin_type): Add BT_HAS_INCLUDE{,_NEXT}.
	* init.c (builtin_array): Add them.
	(cpp_init_builtins): Drop __has_include{,_next} init here ...
	* pch.c (cpp_read_state): ... and here.
	* traditional.c (enum ls): Drop has_include states ...
	(_cpp_scan_out_logical_line): ... and here.

I noticed, but ignored this code when addressing p80005, but having
fixed up defined(X) on the modules branch, I could see where it came
from, and it's obviously wrong as we've just pulled out a string
contant from the token.

	* expr.c (parse_has_include): Remove bogus controlling macro code.

__has_include is funky in that it is macro-like from the POV of #ifdef and
friends, but lexes its parenthesize argument #include-like.  We were
failing the second part of that, because we used a forwarding macro to an
internal name, and hence always lexed the argument in macro-parameter
context.  We componded that by not setting the right flag when lexing, so
it didn't even know.  Mostly users got lucky.

This reimplements the handline.
1) Remove the forwarding, but declare object-like macros that
expand to themselves.  This satisfies the #ifdef requirement

2) Correctly set angled_brackets when lexing the parameter.  This tells
the lexer (a) <...> is a header name and (b) "..." is too (not a string).

3) Remove the in__has_include lexer state, just tell find_file that that's
what's happenning, so it doesn't emit an error.

We lose the (undocumented) ability to #undef __has_include.  That may well
have been an accident of implementation.  There are no tests for it.

We gain __has_include behaviour for all users of the preprocessors -- not
just the C-family ones that defined a forwarding macro.

	libcpp/
	PR preprocessor/80005
	* include/cpplib.h (BT_HAS_ATTRIBUTE): Fix comment.
	* internal.h (struct lexer_state): Delete in__has_include field.
	(struct spec_nodes): Rename n__has_include{,_next}__ fields.
	(_cpp_defined_macro_p): New.
	(_cpp_find_file): Add has_include parm.
	* directives.c (lex_macro_node): Combine defined,
	__has_inline{,_next} checking.
	(do_ifdef, do_ifndef): Use _cpp_defined_macro_p.
	(_cpp_init_directives): Refactor.
	* expr.c (parse_defined): Use _cpp_defined_macro_p.
	(eval_token): Adjust parse_has_include calls.
	(parse_has_include): Add OP parameter.  Reimplement.
	* files.c (_cpp_find_file): Add HAS_INCLUDE parm.  Use it to
	inhibit error message.
	(_cpp_stack_include): Adjust _cpp_find_file call.
	(_cpp_fake_include, _cpp_compare_file_date): Likewise.
	(open_file_failed): Remove in__has_include check.
	(_cpp_has_header): Adjust _cpp_find_file call.
	* identifiers.c (_cpp_init_hashtable): Don't init
	__has_include{,_next} here ...
	* init.c (cpp_init_builtins): ... init them here.  Define as
	macros.
	(cpp_read_main_file): Adjust _cpp_find_file call.
	* pch.c (cpp_read_state): Adjust __has_include{,_next} access.
	* traditional.c (_cpp_scan_out_locgical_line): Likewise.

	gcc/c-family/
	PR preprocessor/80005
	* c-cppbuiltins.c (c_cpp_builtins): Don't define __has_include{,_next}.

	gcc/testsuite/
	PR preprocessor/80005
	* g++.dg/cpp1y/feat-cxx14.C: Adjust.
	* g++.dg/cpp1z/feat-cxx17.C: Adjust.
	* g++.dg/cpp2a/feat-cxx2a.C: Adjust.
	* g++.dg/cpp/pr80005.C: New.

the preprocessor evaluator has a skip_eval counter, but we weren't
checking it after parsing has_include(foo), but before looking for
foo.  Resulting in unnecessary io for 'FALSE_COND && has_include <foo>'

	PR preprocessor/93306
	* expr.c (parse_has_include): Refactor.  Check skip_eval before
	looking.