The C++26 https://wg21.link/P3348R4 C++26 should refer to C23 not C17
paper among other things changes va_start macro in the similar way
how C23 has changed it.  Now, unlike C17 and older, C++ has since forever
allowed int (...) but just one wasn't able to use va_start/va_arg/va_end
in such functions.
With the current C++26 draft wording, we'd have to
  #define va_start(V, ...) __builtin_va_start (V, 0)
like we've used for C23 before the PR107980 change.
But Jonathan has kindly filed
https://cplusplus.github.io/LWG/issue4388
which similarly to C23 will if accepted allow to define it as
  #define va_start(...) __builtin_c23_va_start(__VA_ARGS__)
and let the compiler diagnose undesirable cases (see stdarg6.C
testcase in the patch for what it can diagnose, basically anything
that isn't either va_start (ap) or va_start (ap, i) where i is the
last argument's identifier).  This patch implements what assumes
LWG4388 will pass.

It also defines
  #define __STDC_VERSION_STDARG_H__ 202311L
also for C++26.

The hardest part is actually something different.
C23 had to differentiate between C99 void foo (); i.e. unspecified
arguments (but not stdarg) and the new C23 void bar (...); which
is stdarg, but in both cases TYPE_ARG_TYPES (fntype) is NULL.
This has been implemented through the new TYPE_NO_NAMED_ARGS_STDARG_P
flag, fntypes with that flag set are considered stdarg_p and allow
va_start in those, while fntypes with NULL TYPE_ARG_TYPES but the
flag cleared are not stdarg_p, can accept any number of arguments
but can't use va_start.
So, I had to change various places in the C++ FE to pass true
as the third argument to build_function_type for calls which are
meant to be (...) so that one can actually use va_start in those.
Done only for C++26 in order not to disturb older versions too much.
And there is a problem with some of the builtins and #pragma weak
which are using (...) declarations more in the sense of C17
unspecified arguments rather than this call has variable arguments.

So, structural_comptypes now considers the non-C++26 (...) used
for selected builtins and #pragma weak incompatible with C++26 (...)
to avoid ICEs.

2025-10-09  Jakub Jelinek  <jakub@redhat.com>

gcc/
	* ginclude/stdarg.h (va_start): Use __builtin_c23_va_start
	also for C++26.
	(__STDC_VERSION_STDARG_H__): Also define for C++26.
gcc/c-family/
	* c-common.h (D_CXX26): Define.
	* c-common.cc (c_common_resword): Add D_CXX26 to
	__builtin_c23_va_start flags, mention D_CXX26 in comment.
gcc/cp/
	* cp-tree.h (cp_build_function_type): Declare.
	* lex.cc: Implement va_start changes from P3348R4 - C++26 should
	refer to C23 not C17 paper.
	(init_reswords): Set D_CXX26 in mask for C++23 and older.
	* parser.cc (cp_parser_primary_expression): Handle RID_C23_VA_START.
	(cp_parser_builtin_c23_va_start): New function.
	* cp-objcp-common.cc (names_builtin_p): Likewise.
	* decl.cc (grokfndecl, check_function_type): Pass
	TYPE_NO_NAMED_ARGS_STDARG_P as last arg to build_function_type.
	(grokdeclarator, static_fn_type): Use cp_build_function_type instead
	of build_function_type.
	* typeck.cc (merge_types): Likewise.
	(structural_comptypes): Return false for TYPE_NO_NAMED_ARGS_STDARG_P
	differences.
	* lambda.cc (maybe_add_lambda_conv_op): Use cp_build_function_type
	instead of build_function_type.
	* tree.cc (cp_build_function_type): New function.
	(strip_typedefs): Pass TYPE_NO_NAMED_ARGS_STDARG_P as last arg to
	build_function_type.
	* name-lookup.cc (push_local_extern_decl_alias): Likewise.
	* module.cc (trees_in::tree_node): Use cp_build_function_type instead
	of build_function_type.
	* pt.cc (copy_default_args_to_explicit_spec,
	rebuild_function_or_method_type, build_deduction_guide): Likewise.
	(alias_ctad_tweaks): Pass TYPE_NO_NAMED_ARGS_STDARG_P as last arg to
	build_function_type.
	* decl2.cc (change_return_type, cp_reconstruct_complex_type):
	Likewise.
gcc/testsuite/
	* c-c++-common/cpp/has-builtin-4.c: Expect
	__has_builtin (__builtin_c23_va_start) == 1 also for C++26.
	* c-c++-common/Wvarargs.c (foo3): Don't expect undefined behavior
	warning for C++26.
	* g++.dg/cpp26/stdarg1.C: New test.
	* g++.dg/cpp26/stdarg2.C: New test.
	* g++.dg/cpp26/stdarg3.C: New test.
	* g++.dg/cpp26/stdarg4.C: New test.
	* g++.dg/cpp26/stdarg5.C: New test.
	* g++.dg/cpp26/stdarg6.C: New test.
	* g++.dg/cpp26/stdarg7.C: New test.
	* g++.dg/cpp26/stdarg8.C: New test.
	* g++.dg/cpp26/stdarg9.C: New test.
	* g++.dg/opt/pr60849.C (foo): Add explicit cast.

comp_template_parms_position uses whether a TEMPLATE_TYPE_PARM is a pack
to determine equivalency.  This in turn affects whether
canonical_type_parameter finds a pre-existing auto type as equivalent.

When generating the 'auto...' type for a lambda pack capture, we only
mark it as a pack after generating the node (and calculating its
canonical); this means that later when comparing a version streamed in
from a module we think that two equivalent types have different
TYPE_CANONICAL, because the latter already had
TEMPLATE_PARM_PARAMETER_PACK set before calculating its canonical.

This patch fixes this by using a new 'make_auto_pack' function to ensure
that packness is set before the canonical is looked up.

	PR c++/122015

gcc/cp/ChangeLog:

	* cp-tree.h (make_auto_pack): Declare.
	* lambda.cc (lambda_capture_field_type): Use make_auto_pack to
	ensure TYPE_CANONICAL is set correctly.
	* pt.cc (make_auto_pack): New function.

gcc/testsuite/ChangeLog:

	* g++.dg/modules/lambda-11.h: New test.
	* g++.dg/modules/lambda-11_a.H: New test.
	* g++.dg/modules/lambda-11_b.C: New test.

Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Patrick Palka <ppalka@redhat.com>

	PR c++/119048

gcc/cp/ChangeLog:

	* lambda.cc (compare_lambda_sig): Only skip first parameter for
	object members.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp23/static-operator-call8.C: New test.

Reviewed-by: Jason Merrill <jason@redhat.com>

This patch is an attempt to implement P2036R3 along with P2579R0, fixing
build breakages caused by P2036R3.

The simplest example is:

  auto counter1 = [j=0]() mutable -> decltype(j) {
      return j++;
  };

which currently doesn't compile because the 'j' in the capture isn't
visible in the trailing return type.  With these proposals, the 'j'
will be in a lambda scope which spans the trailing return type, so
this test will compile.

This oughtn't be difficult but decltype and other issues made this patch
much more challenging.

We have to push the explicit captures before going into
_lambda_declarator_opt because that is what parses the trailing return
type.  Yet we can't build any captures until after _lambda_body ->
start_lambda_function which creates the lambda's operator(), without
which we can't build a proxy, but _lambda_body happens only after
parsing the declarator.  This patch works around it by creating a fake
operator() and adding it to the capture and then removing it when we
have the real operator().

Another thing is that in "-> decltype(j)" we don't have the right
current_function_decl yet.  If current_lambda_expr gives us a lambda,
we know this decltype appertains to a lambda.  But we have to know if we
are in a parameter-declaration-clause: as per [expr.prim.id.unqual]/4.4,
if we are, we shouldn't be adding "const".  The new LAMBDA_EXPR_CONST_QUAL_P
flag tracks this.  But it doesn't handle nested lambdas yet, specifically,
[expr.prim.id.unqual]/14.

I don't think this patch changes behavior for the tests in
"capture-default with [=]" as the paper promises; clang++ behaves the
same as gcc with this patch.

	PR c++/102610

gcc/cp/ChangeLog:

	* cp-tree.h (LAMBDA_EXPR_CONST_QUAL_P): Define.
	(maybe_add_dummy_lambda_op): Declare.
	(remove_dummy_lambda_op): Declare.
	(push_capture_proxies): Adjust.
	* lambda.cc (build_capture_proxy): No longer static.  New early_p
	parameter.  Use it.
	(add_capture): Adjust the call to build_capture_proxy.
	(resolvable_dummy_lambda): Check DECL_LAMBDA_FUNCTION_P.
	(push_capture_proxies): New.
	(start_lambda_function): Use it.
	* name-lookup.cc (check_local_shadow): Give an error for
	is_capture_proxy.
	(cp_binding_level_descriptor): Add lambda-scope.
	(begin_scope) <case sk_lambda>: New case.
	* name-lookup.h (enum scope_kind): Add sk_lambda.
	(struct cp_binding_level): Widen kind.
	* parser.cc (cp_parser_lambda_expression): Create a new (lambda) scope
	after the lambda-introducer.
	(cp_parser_lambda_declarator_opt): Set LAMBDA_EXPR_CONST_QUAL_P.
	Create a dummy operator() if needed.  Inject the captures into the
	lambda scope.  Remove the dummy operator().
	(make_dummy_lambda_op): New.
	(maybe_add_dummy_lambda_op): New.
	(remove_dummy_lambda_op): New.
	* pt.cc (tsubst_lambda_expr): Begin/end a lambda scope.  Push the
	capture proxies.  Build/remove a dummy operator() if needed.  Set
	LAMBDA_EXPR_CONST_QUAL_P.
	* semantics.cc (parsing_lambda_declarator): New.
	(outer_var_p): Also consider captures as outer variables if in a lambda
	declarator.
	(process_outer_var_ref): Reset containing_function when
	parsing_lambda_declarator.
	(finish_decltype_type): Process decls in the lambda-declarator as well.
	Look at LAMBDA_EXPR_CONST_QUAL_P unless we have an xobj function.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/lambda/lambda-decltype3.C: Remove xfail.
	* g++.dg/warn/Wshadow-19.C: Add -Wpedantic.  Adjust a dg-warning.
	* g++.dg/warn/Wshadow-6.C: Adjust expected diagnostics.
	* g++.dg/cpp23/lambda-scope1.C: New test.
	* g++.dg/cpp23/lambda-scope2.C: New test.
	* g++.dg/cpp23/lambda-scope3.C: New test.
	* g++.dg/cpp23/lambda-scope4.C: New test.
	* g++.dg/cpp23/lambda-scope4b.C: New test.
	* g++.dg/cpp23/lambda-scope5.C: New test.
	* g++.dg/cpp23/lambda-scope6.C: New test.
	* g++.dg/cpp23/lambda-scope7.C: New test.
	* g++.dg/cpp23/lambda-scope8.C: New test.
	* g++.dg/cpp23/lambda-scope9.C: New test.

Reviewed-by: Jason Merrill <jason@redhat.com>

This patch implements consteval blocks, as specified by P2996.
They aren't very useful without define_aggregate, but having
a reviewed implementation on trunk would be great.

consteval {} can be anywhere where a member-declaration or
block-declaration can be.  The expression corresponding to it is:

  [] -> void static consteval compound-statement ()

and it must be a constant expression.

I've used cp_parser_lambda_expression to take care of most of the
parsing.  Since a consteval block can find itself in a template, we
need a vehicle to carry the block for instantiation.  Rather than
inventing a new tree, I'm using STATIC_ASSERT.

A consteval block can't return a value but that is checked by virtue
of the lambda having a void return type.

	PR c++/120775

gcc/cp/ChangeLog:

	* constexpr.cc (cxx_eval_outermost_constant_expr): Use
	extract_call_expr.
	* cp-tree.h (CONSTEVAL_BLOCK_P, LAMBDA_EXPR_CONSTEVAL_BLOCK_P): Define.
	(finish_static_assert): Adjust declaration.
	(current_nonlambda_function): Likewise.
	* lambda.cc (current_nonlambda_function): New parameter.  Only keep
	iterating if the function represents a consteval block.
	* parser.cc (cp_parser_lambda_expression): New parameter for
	consteval blocks.  Use it.  Set LAMBDA_EXPR_CONSTEVAL_BLOCK_P.
	(cp_parser_lambda_declarator_opt): Likewise.
	(build_empty_string): New.
	(cp_parser_next_tokens_are_consteval_block_p): New.
	(cp_parser_consteval_block): New.
	(cp_parser_block_declaration): Handle consteval blocks.
	(cp_parser_static_assert): Use build_empty_string.
	(cp_parser_member_declaration): Handle consteval blocks.
	* pt.cc (tsubst_stmt): Adjust a call to finish_static_assert.
	* semantics.cc (finish_fname): Warn for consteval blocks.
	(finish_static_assert): New parameter for consteval blocks.  Set
	CONSTEVAL_BLOCK_P.  Evaluate consteval blocks specially.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp26/consteval-block1.C: New test.
	* g++.dg/cpp26/consteval-block2.C: New test.
	* g++.dg/cpp26/consteval-block3.C: New test.
	* g++.dg/cpp26/consteval-block4.C: New test.
	* g++.dg/cpp26/consteval-block5.C: New test.
	* g++.dg/cpp26/consteval-block6.C: New test.
	* g++.dg/cpp26/consteval-block7.C: New test.
	* g++.dg/cpp26/consteval-block8.C: New test.

Reviewed-by: Jason Merrill <jason@redhat.com>

The lambda conversion was ICEing for two C++23 features, static op() and
explicit object parameters.  The issue with the former seems like a more
general issue: tsubst_function_decl recursing to substitute the parameters
was affected by cp_unevaluated_operand from the decltype that refers to the
declaration.  Various places already make a point of clearing
cp_unevaluated_operand ahead of PARM_DECL tsubsting; doing it here makes the
PR101233 fix redundant.

For explicit object lambdas, we want to implement CWG2561 and
just not declare the conversion.

	PR c++/114632
	PR c++/101233

gcc/cp/ChangeLog:

	* lambda.cc (maybe_add_lambda_conv_op): Not for xobj lambda.
	* pt.cc (tsubst_function_decl): Add cp_evaluated.
	(alias_ctad_tweaks): Revert PR101233 fix.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp23/explicit-obj-lambda18.C: New test.
	* g++.dg/cpp23/static-operator-call7.C: New test.

The following patch implements the
/* FIXME reuse another field?  */
comment on the lambda_expr member.
I think (and asserts in the patch seem to confirm) CLASSTYPE_KEY_METHOD
is only ever non-NULL for TYE_POLYMORPHIC_P and on the other side
CLASSTYPE_LAMBDA_EXPR is only used on closure types which are never
polymorphic.

So, the patch just uses one member for both, with the accessor macros
changed to be no longer lvalues and adding SET_* variants of the macros
for setters.

2025-07-11  Jakub Jelinek  <jakub@redhat.com>

	* cp-tree.h (struct lang_type): Add comment before key_method.
	Remove lambda_expr.
	(CLASSTYPE_KEY_METHOD): Give NULL_TREE if not TYPE_POLYMORPHIC_P.
	(SET_CLASSTYPE_KEY_METHOD): Define.
	(CLASSTYPE_LAMBDA_EXPR): Give NULL_TREE if TYPE_POLYMORPHIC_P.
	Use key_method member instead of lambda_expr.
	(SET_CLASSTYPE_LAMBDA_EXPR): Define.
	* class.cc (determine_key_method): Use SET_CLASSTYPE_KEY_METHOD
	macro.
	* decl.cc (xref_tag): Use SET_CLASSTYPE_LAMBDA_EXPR macro.
	* lambda.cc (begin_lambda_type): Likewise.
	* module.cc (trees_in::read_class_def): Use SET_CLASSTYPE_LAMBDA_EXPR
	and SET_CLASSTYPE_KEY_METHOD macros, assert lambda is NULL if
	TYPE_POLYMORPHIC_P and otherwise assert key_method is NULL.

In this testcase there is nothing in the lambda except a static_assert which
mentions a variable from the enclosing scope but does not odr-use it, so we
want prune_lambda_captures to remove its capture.  Since the lambda is so
empty, there's nothing in the body except the DECL_EXPR of the capture
proxy, so pop_stmt_list moves that into the enclosing STATEMENT_LIST and
passes the 'body' STATEMENT_LIST to free_stmt_list.  As a result, passing
'body' to prune_lambda_captures is wrong; we should instead pass the
enclosing scope, i.e. cur_stmt_list.

	PR c++/120716

gcc/cp/ChangeLog:

	* lambda.cc (finish_lambda_function): Pass cur_stmt_list to
	prune_lambda_captures.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/lambda/lambda-constexpr3.C: New test.
	* g++.dg/cpp0x/lambda/lambda-constexpr3a.C: New test.

This testcase was crashing from infinite recursion in the diagnostic
machinery, trying to print the lambda signature, which referred to the
__this capture field in the lambda, which wanted to print the lambda again.

But we don't want the signature to refer to the capture field; 'this' in an
unevaluated context refers to the 'this' from the enclosing function, not
the capture.

After fixing that, we still wrongly rejected the B case because
THIS_FORBIDDEN is set in a default (template) argument.  Since we don't
distinguish between THIS_FORBIDDEN being set for a default argument and it
being set for a static member function, let's just ignore it if
cp_unevaluated_operand; we'll give a better diagnostic for the static memfn
case in finish_this_expr.

	PR c++/120748

gcc/cp/ChangeLog:

	* lambda.cc (lambda_expr_this_capture): Don't return a FIELD_DECL.
	* parser.cc (cp_parser_primary_expression): Ignore THIS_FORBIDDEN
	if cp_unevaluated_operand.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp2a/lambda-targ16.C: New test.
	* g++.dg/cpp0x/this1.C: Adjust diagnostics.

Nathaniel shared a more extensive test, which revealed more needed fixes.

	PR c++/113563

gcc/cp/ChangeLog:

	* lambda.cc (lambda_capture_field_type): Handle 'this' normally.
	(build_capture_proxy): Special-case 'this' by-ref capture more.
	(nonlambda_method_basetype): Look through xobj lambdas.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp23/explicit-obj-lambda17.C: New test.