c: Handle scoped attributes in __has*attribute and scoped attribute parsing changes in -std=c11 etc. modes [PR114007]

We aren't able to parse __has_attribute (vendor::attr) (and __has_c_attribute
and __has_cpp_attribute) in strict C < C23 modes.  While in -std=gnu* modes
or in -std=c23 there is CPP_SCOPE token, in -std=c* (except for -std=c23)
there are is just a pair of CPP_COLON tokens.
The c-lex.cc hunk adds support for that.

That leads to a question if we should return 1 or 0 from
__has_attribute (gnu::unused) or not, because while
[[gnu::unused]] is parsed fine in -std=gnu*/-std=c23 modes (sure, with
pedwarn for < C23), we do not parse it at all in -std=c* (except for
-std=c23), we only parse [[__extension__ gnu::unused]] there.  While
the __extension__ in there helps to avoid the pedwarn, I think it is
better to be consistent between GNU and strict C < C23 modes and
parse [[gnu::unused]] too; on the other side, I think parsing
[[__extension__ gnu : : unused]] is too weird and undesirable.

So, the following patch adds a flag during preprocessing at the point
where we normally create CPP_SCOPE tokens out of 2 consecutive colons
on the first CPP_COLON to mark the consecutive case (as we are tight
on the bits, I've reused the PURE_ZERO flag, which is used just by the
C++ FE and only ever set (both C and C++) on CPP_NUMBER tokens, this
new flag has the same value and is only ever used on CPP_COLON tokens)
and instead of checking loose_scope_p argument (i.e. whether it is
[[__extension__ ...]] or not), it just parses CPP_SCOPE or CPP_COLON
with CLONE_SCOPE flag followed by another CPP_COLON the same.
The latter will never appear in >= C23 or -std=gnu* modes, though
guarding its use say with flag_iso && !flag_isoc23 && doesn't really
work because the __extension__ case temporarily clears flag_iso flag.

This makes the -std=c11 etc. behavior more similar to -std=gnu11 or
-std=c23, the only difference I'm aware of are the
 #define JOIN2(A, B) A##B
 [[vendor JOIN2(:,:) attr]]
 [[__extension__ vendor JOIN2(:,:) attr]]
cases, which are accepted in the latter modes, but results in error
in -std=c11; but the error is during preprocessing that :: doesn't
form a valid preprocessing token, which is true, so just don't do that if
you try to have __STRICT_ANSI__ && __STDC_VERSION__ <= 201710L
compatibility.

2024-02-22  Jakub Jelinek  <jakub@redhat.com>

	PR c/114007
gcc/
	* doc/extend.texi: (__extension__): Remove comments about scope
	tokens vs. two colons.
gcc/c-family/
	* c-lex.cc (c_common_has_attribute): Parse 2 CPP_COLONs with
	the first one with COLON_SCOPE flag the same as CPP_SCOPE.
gcc/c/
	* c-parser.cc (c_parser_std_attribute): Remove loose_scope_p argument.
	Instead of checking it, parse 2 CPP_COLONs with the first one with
	COLON_SCOPE flag the same as CPP_SCOPE.
	(c_parser_std_attribute_list): Remove loose_scope_p argument, don't
	pass it to c_parser_std_attribute.
	(c_parser_std_attribute_specifier): Adjust c_parser_std_attribute_list
	caller.
gcc/testsuite/
	* gcc.dg/c23-attr-syntax-6.c: Adjust testcase for :: being valid
	even in -std=c11 even without __extension__ and : : etc. not being
	valid anymore even with __extension__.
	* gcc.dg/c23-attr-syntax-7.c: Likewise.
	* gcc.dg/c23-attr-syntax-8.c: New test.
libcpp/
	* include/cpplib.h (COLON_SCOPE): Define to PURE_ZERO.
	* lex.cc (_cpp_lex_direct): When lexing CPP_COLON with another
	colon after it, if !CPP_OPTION (pfile, scope) set COLON_SCOPE
	flag on the first CPP_COLON token.