Re: [C++ Patch] Remove is_auto_or_concept, etc

Sorry for not getting back to your original post Paolo. I haven't been picking up mails for a while. On 2017-05-01 16:56, Jason Merrill wrote: On Thu, Apr 27, 2017 at 2:02 PM, Paolo Carlini wrote: On 26/04/2017 12:32, Paolo Carlini wrote: in 2013 (2013-09-16)

[PATCH] Fix PR c++/64382

Hi Jason, I've reopened 64382 and unhooked it from 61636 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64382#c6). This is a rebase of my original patch for 64382 from April 2015 against latest master. My query about caching parsing_default_capturing_generic_lambda_in_template() still applies.

[PATCH] Re: PR c++/69139

The following fixes up the handling of trailing returns with cv/ref specifiers mentioned by TC in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69139#c3. I've added handling of exception and transaction specs too. --- gcc/cp/parser.c | 12 ++--

Re: [PATCH] PR c++/69139

On 2016-02-08 19:14, Patrick Palka wrote: On Mon, 8 Feb 2016, Jason Merrill wrote: On 02/08/2016 11:43 AM, Patrick Palka wrote: BTW, last month I posted a patch for this PR that handles all kinds of specifiers as well __attribute__ specifiers. Patch is at:

[PATCH] PR c++/69139

PR c++/69139 * cp/parser.c (cp_parser_simple_type_specifier): Don't mistake 'auto' in trailing return function pointer types as an implicit template parameter. PR c++/69139 * g++.dg/cpp0x/trailing12.C: New test. --- gcc/cp/parser.c

Re: [PATCH 1/2] ?PR c++/61636

On 2015-04-20 11:25, Marek Polacek wrote: On Sat, Apr 18, 2015 at 06:53:28PM +0100, Adam Butcher wrote: Test like this? /* { dg-do run { target c++14 } } */ /* { dg-final { scan-assembler-not ... } } */ What is this dg-final supposed to do here? It was a placeholder for making sure

Re: [PATCH 1/2] PR c++/61636

On 2015-04-18 18:53, Adam Butcher wrote: Test like this? /* { dg-do run { target c++14 } } */ /* { dg-final { scan-assembler-not ... } } */ struct X { int f (int, double) { return 255; } static int f (int, int) { return 65535; } auto m1 () { return [=] (auto a) { return f

Re: [PATCH 1/2] PR c++/61636

On 2015-04-17 22:06, Adam Butcher wrote: On 2015-04-17 20:58, Jason Merrill wrote: On 04/09/2015 11:31 PM, Adam Butcher wrote: + /* For generic lambdas, resolve default captured 'this' now. */ This isn't quite right. We don't want to capture 'this' any time we see a member

Re: [PATCH 1/2] PR c++/61636

On 2015-04-17 20:58, Jason Merrill wrote: On 04/09/2015 11:31 PM, Adam Butcher wrote: + /* For generic lambdas, resolve default captured 'this' now. */ This isn't quite right. We don't want to capture 'this' any time we see a member function call, as overload resolution might

Re: [PATCH 2/2] PR c++/64382 * cp/parser.c (parsing_default_capturing_generic_lambda_in_template): New function. * cp/cp-tree.h: Declare it. * cp/semantics.c (finish_id_expression): Resolve names

On 2015-04-14 8:26, Jakub Jelinek wrote: I'd say best would be to just use separate ifs with return false. Done.

Re: [PATCH 2/2] PR c++/64382 * cp/parser.c (parsing_default_capturing_generic_lambda_in_template)...

On 2015-04-10 4:31, Adam Butcher wrote: +parsing_default_capturing_generic_lambda_in_template (void) I'm wondering whether we should cache this as a bool on the parser. Currently it is called once per id-expression and will always return the same result for any given lambda.

[PATCH] PR c++/65750

* cp/parser.c (cp_parser_simple_type_specifier): Don't synthesize implicit template parm if 'auto' is a placeholder for trailing return type. --- gcc/cp/parser.c | 23 +++ gcc/testsuite/g++.dg/cpp1y/pr65750.C | 12 2

Re: [PATCH] PR c++/65750

On 2015-04-10 15:57, Adam Butcher wrote: + cp_lexer_consume_token (parser-lexer); Actually there should be two of these as the 'auto' isn't consumed yet.

[PATCH 1/2] PR c++/61636 * cp/parser.c (cp_parser_postfix_expression): Resolve default captured 'this' early for generic lambdas.

PR c++/61636 * g++.dg/cpp1y/pr61636.C: New test. --- gcc/cp/parser.c | 16 gcc/testsuite/g++.dg/cpp1y/pr61636.C | 19 +++ 2 files changed, 35 insertions(+) create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr61636.C diff --git

[PATCH] [PR c++/61636 and c++/64382] Fix default capture in generic lambdas

Hi Jason, I finally scraped some time together to look into these two generic lambda default capture bugs and believe I have a solution. Still have to run tests but I thought I'd get these out for your perusal whilst I rebase onto origin/master and run the testsuite. Cheers, Adam

[PATCH 2/2] PR c++/64382 * cp/parser.c (parsing_default_capturing_generic_lambda_in_template): New function. * cp/cp-tree.h: Declare it. * cp/semantics.c (finish_id_expression): Resolve names wit

PR c++/64382 * g++.dg/cpp1y/pr64382.C: New test. --- gcc/cp/cp-tree.h | 1 + gcc/cp/parser.c | 21 + gcc/cp/semantics.c | 8 +--- gcc/testsuite/g++.dg/cpp1y/pr64382.C | 23 +++

Re: Patch for constexpr variable templates

On 2014-07-28 3:06, Braden Obrzut wrote: So given this, should I leave the test cases that fail for this reason alone or should I still change them to dg-message? I'm not sure what GCC's policy is here, Jason will. It sounds like GCC's behavior with auto in function parameters needs to be

Re: Patch for constexpr variable templates

On 2014-07-28 13:09, Andrew Sutton wrote: 3) auto (*f (auto)) (auto); // generic function 'f' constrained to returning a unary function pointer deduced from the return expression. Really? I've read the comment and I'm still not sure how to read this declaration. The first and last 'auto'

Re: Patch for constexpr variable templates

On 2014-07-26 17:14, Jason Merrill wrote: On 07/26/2014 12:11 PM, Jason Merrill wrote: On 07/26/2014 03:04 AM, Braden Obrzut wrote: On 07/25/2014 05:24 PM, Jason Merrill wrote: Fair enough, but in that case let's use 'sorry' rather then 'error' to be clear that it's a missing feature.

Re: Patch for constexpr variable templates

On 2014-07-27 19:01, Andrew Sutton wrote: In the 59638 case, the declarations void (*a)(auto); void (*b)(auto) = 0; are shorthand for template typename T void (*a)(T); template typename T void (*b)(T) = 0; which, unless there's some constraint with variable templates that I'm not

Re: [PATCH] Fix PR c++/61537

* parser.c (cp_parser_elaborated_type_specifier): Only consider template parameter lists outside of function parameter scope. * g++.dg/template/pr61537.C: New testcase. --- gcc/cp/parser.c | 31 ++-

Re: [PATCH] Fix PR c++/61537

On 2014-06-25 21:57, Jason Merrill wrote: OK, thanks. Do you want me to apply to 4.9 too?

[PATCH] Fix PR c++/61537

* parser.c (cp_parser_elaborated_type_specifier): Only consider template parameter lists outside of function parameter scope. * g++.dg/cpp1y/pr61537.C: New testcase. --- gcc/cp/parser.c | 28 +++-

Re: [PATCH] Fix PR c++/61537

On 2014-06-24 23:22, Paolo Carlini wrote: On 06/24/2014 01:40 AM, Adam Butcher wrote: +// { dg-do compile { target c++1y } } I don't think this is a C++1y specific issue... You're right. I'm so used to creating pr testcases in that g++.dg/cpp1y dir, I automatically added the test

[wwwdocs] Mention generic functions and explicit lambda templates in gcc-4.9/changes

Hi, The following patch adds details of support for generic functions and the explicit template parameter extension for generic lambdas present in GCC 4.9. OK to commit? Cheers, Adam Index: htdocs/gcc-4.9/changes.html === RCS

Re: [PATCH] Fix PR c++/60573

On 2014-03-27 21:16, Adam Butcher wrote: On 2014-03-27 20:45, Adam Butcher wrote: PR c++/60573 * name-lookup.h (cp_binding_level): New field scope_defines_class_p. * semantics.c (begin_class_definition): Set scope_defines_class_p. * pt.c (instantiate_class_template_1): Likewise. * parser.c

[PATCH] Fix PR c++/60573

PR c++/60573 * name-lookup.h (cp_binding_level): New transient field defining_class_p to indicate whether a scope is in the process of defining a class. * semantics.c (begin_class_definition): Set defining_class_p. * name-lookup.c (leave_scope): Reset

[PATCH] Fix PR c++/60573

PR c++/60573 * name-lookup.h (cp_binding_level): New field scope_defines_class_p. * semantics.c (begin_class_definition): Set scope_defines_class_p. * pt.c (instantiate_class_template_1): Likewise. * parser.c (synthesize_implicit_template_parm): Use

Re: [PATCH] Fix PR c++/60573

On 2014-03-27 20:45, Adam Butcher wrote: @@ -8905,9 +8905,12 @@ instantiate_class_template_1 (tree type) return type; /* Now we're really doing the instantiation. Mark the type as in - the process of being defined. */ + the process of being defined... */ TYPE_BEING_DEFINED

Re: [PATCH] Fix PR c++/60573

On 2014-03-27 20:45, Adam Butcher wrote: PR c++/60573 * name-lookup.h (cp_binding_level): New field scope_defines_class_p. * semantics.c (begin_class_definition): Set scope_defines_class_p. * pt.c (instantiate_class_template_1): Likewise. * parser.c

Re: [PATCH] Fix PR c++/60573

On 2014-03-26 15:17, Jason Merrill wrote: I meant struct A { struct X { struct B { void foo(auto); }; void B::foo(auto) {} // { dg-error cannot define } }; }; Here we push both A and X for the declarator. When we get to the pushed X, we see

Re: [PATCH] Fix PR c++/60573

On 2014-03-25 15:48, Jason Merrill wrote: I think we need some way to designate a scope that actually corresponds to a class-specifier. Agreed. I'll look into it. Adam

[PATCH] Fix PR c++/60573

PR c++/60573 * parser.c (synthesize_implicit_template_parm): Use cp_binding_level:: class_shadowed rather than TYPE_BEING_DEFINED as the predicate for unwinding to class-defining scope to handle the erroneous definition of a generic function of an

Re: [PATCH] Fix PR c++/60573

On 2014-03-25 15:48, Jason Merrill wrote: On 03/18/2014 10:46 PM, Adam Butcher wrote: + if (TYPE_BEING_DEFINED (scope-this_entity)) + if (scope-level_chain == 0 + || scope-this_entity != scope-level_chain-this_entity) + break; I

[PATCH] [C++ RFC] Support named type capture for generic lambdas and generic functions as proposed by N3878

* parser.c (cp_parser_simple_type_specifier): Lookahead for a braced identifier after a generic type ('auto') parameter and, if present, use that as the type identifier name. Otherwise generate one with make_generic_type_name. Pass the resulting identifier as the

Re: [PATCH] Fix PR c++/60573

On 2014-03-24 17:23, Jason Merrill wrote: On 03/18/2014 10:46 PM, Adam Butcher wrote: - while (scope-kind == sk_class - !TYPE_BEING_DEFINED (scope-this_entity)) Does it work to just change TYPE_BEING_DEFINED to currently_open_class? No. The object referred

[PATCH] Fix PR c++/60626

PR c++/60626 * parser.c (cp_parser_init_declarator): Handle erroneous generic type usage in non-functions with pushed scope. PR c++/60626 * g++.dg/cpp1y/pr60626.C: New testcase. --- gcc/cp/parser.c | 9 -

[PATCH] Fix PR c++/60627

PR c++/60627 * parser.c (cp_parser_parameter_declaration_clause): Prevent 'auto' from introducing an implicit function template parameter within an explicit instantiation. PR c++/60627 * g++.dg/cpp1y/pr60627.C: New testcase. --- gcc/cp/parser.c

[PATCH] Fix PR c++/60573

PR c++/60573 * parser.c (synthesize_implicit_template_parm): Handle the fact that nested class member declarations erroneously appearing in an enclosing class contain an addition scope level for the class being defined. PR c++/60573 *

[PATCH] Fix PR c++/60390

PR c++/60390 * parser.c (cp_parser_member_declaration): Don't allow finish_fully_implicit_template to consider friend declarations to be class member templates. (synthesize_implicit_template_parm): Handling winding back through class scope to the

[PATCH] Fix PR c++/60391

PR c++/60391 * parser.c (cp_parser_skip_to_end_of_block_or_statement): Unwind generic function scope as per cp_parser_skip_to_end_of_statement. PR c++/60391 * g++.dg/cpp1y/pr60391.C: New testcase. --- gcc/cp/parser.c | 4

Re: [PATCH] Fix PR c++/60393

On 2014-03-07 17:29, Jason Merrill wrote: On 03/04/2014 04:46 PM, Adam Butcher wrote: PR c++/60393 * parser.c (cp_parser_parameter_declaration_clause): Move generic function template unwinding on error into a move general location, ... (cp_parser_error): ... here

[PATCH] Fix PR c++/60393

PR c++/60393 * parser.c (cp_parser_parameter_declaration_clause): Move generic function template unwinding on error into a more general location, ... (cp_parser_skip_to_end_of_statement): ... here. PR c++/60393 * g++.dg/cpp1y/pr60393.C: New

[PATCH] Fix PR c++/60033

PR c++/60033 * pt.c (retrieve_specialization): When retrieving a capture pack from a generic lambda, remove the lambda's own template argument list prior to fetching the specialization. PR c++/60033 * g++.dg/cpp1y/pr60033.C: New testcase. ---

[PATCH] Fix PR c++/60393

PR c++/60393 * parser.c (cp_parser_parameter_declaration_clause): Move generic function template unwinding on error into a move general location, ... (cp_parser_error): ... here. PR c++/60393 * g++.dg/cpp1y/pr60393.C: New testcase. ---

[PATCH] Fix PR c++/60377.

PR c++/60377 * parser.c (cp_parser_parameter_declaration_clause): Unwind generic function scope on parse error in function parameter list. PR c++/60377 * g++.dg/cpp1y/pr60377.C: New testcase. --- gcc/cp/parser.c | 7 ++-

[PATCH 1/2] Fix PR c++/60065.

PR c++/60065 * parser.c (cp_parser_direct_declarator): Don't save and restore num_template_parameter_lists around call to cp_parser_parameter_declaration_list. (function_being_declared_is_template_p): New predicate.

[PATCH 2/2] Fix out-of-line definition of class template generic member functions.

* parser.c (synthesize_implicit_template_parm): Inject new template argument list appropriately when a generic member function of a class template is declared out-of-line. * g++.dg/cpp1y/fn-generic-member-ool.C: New testcase. --- gcc/cp/parser.c

Re: [PATCH 1/2] Fix PR c++/60065.

On 2014-02-24 18:16, Jason Merrill wrote: On 02/24/2014 02:32 AM, Adam Butcher wrote: +static bool function_being_declared_is_template_p (cp_parser* parser) Function name should be at the beginning of the next line. Doh! Fixed. - if (scope-kind != sk_template_parms) + if (scope

[PATCH] Fix PR c++/60311.

PR c++/60311 * parser.c (function_being_declared_is_template_p): Return false when processing a template parameter list. (cp_parser_parameter_declaration_clause): Don't set auto_is_implicit_function_template_parm_p when processing a template

Re: [PATCH] Fix PR c++/60065.

On 2014-02-21 15:49, Jason Merrill wrote: On 02/21/2014 03:19 AM, Adam Butcher wrote: Jason Merrill wrote: Why doesn't num_template_parameter_lists work as a predicate here? It works in the lambda case as it is updated there, but for generic functions I think the following prevents

Re: [PATCH] Fix PR c++/60065.

On 2014-02-20 16:18, Jason Merrill wrote: On 02/19/2014 10:00 PM, Adam Butcher wrote: + if (current_template_parms) +{ + cp_binding_level *maybe_tmpl_scope = current_binding_level-level_chain; + while (maybe_tmpl_scope maybe_tmpl_scope-kind == sk_class

[PATCH] Fix PR c++/60052.

PR c++/60052 * parser.c (cp_parser_parameter_declaration_list): Correctly reset implicit_template_scope upon leaving an out-of-line generic member function definition. PR c++/60052 * g++.dg/cpp1y/pr60052.C: New testcase. --- gcc/cp/parser.c

Re: [PATCH] Fix PR c++/60052 and c++/60053

On 2014-02-20 1:24, Adam Butcher wrote: PR c++/60052 * parser.c (cp_parser_parameter_declaration_list): Correctly reset implicit_template_scope upon leaving an out-of-line generic member function definition. Turns out this fixes 60053 too.

[PATCH] Fix PR c++/60065.

PR c++/60065 * parser.c (cp_parser_parameter_declaration_list): Use current_template_parms and scope check as predicate for inspecting current function template parameter list length rather than num_template_parameter_lists. PR c++/60065 *

[PATCH] Fix PR c++/60190.

PR c++/60190 * parser.c (cp_parser_lambda_declarator_opt): Pop template parameter scope whenever a template parameter list has been started, independent of whether the function call operator was well-formed or not. PR c++/60190 *

[PATCH] Fix PR c++/60064.

PR c++/60064 * parser.c (cp_parser_member_declaration): Pop fully implicit template scope for generic friend declarations as well as for non-friends. PR c++/60064 * g++.dg/cpp1y/pr60064.C: New testcase. --- gcc/cp/parser.c | 8 +++-

Re: [PATCH] Fix PR c++/59638

On 2014-01-06 14:36, Jason Merrill wrote: On 01/04/2014 04:54 AM, Adam Butcher wrote: + /* Declarations involving function parameter lists containing implicit + template parameters will have been made into implicit templates. If they + do not turn out to be actual function

[PATCH] Fix PR c++/59629

* cp/parser.c (cp_parser_lambda_expression): Save/reset/restore auto_is_implicit_function_template_parm_p around lambda body. * g++.dg/cpp1y/pr59629.C: New testcase. --- gcc/cp/parser.c | 5 + gcc/testsuite/g++.dg/cpp1y/pr59629.C | 7 +++ 2

[PATCH] Fix PR c++/59638

* cp/parser.c (cp_parser_init_declarator): Undo fully implicit template parameter list when declarator is not a function. * g++.dg/cpp1y/pr59638.C: New testcase. --- gcc/cp/parser.c | 8 gcc/testsuite/g++.dg/cpp1y/pr59638.C | 16

[PATCH] Fix PR c++/59635

* cp/lambda.c (maybe_add_lambda_conv_op): Handle marking conversion function as unimplemented for generic lambdas with varargs. * g++.dg/opt/pr59635.C: New testcase. --- gcc/cp/lambda.c | 2 +- gcc/testsuite/g++.dg/cpp1y/pr59635.C | 9 + 2

[PATCH] Fix PR c++/59636

* cp/parser.c (cp_parser_template_parameter): Early out with error_mark_node if parameter declaration was not parsed. * g++.dg/cpp1y/pr59636.C: New testcase. --- gcc/cp/parser.c | 12 ++-- gcc/testsuite/g++.dg/cpp1y/pr59636.C | 7 +++ 2

Re: [PATCH] Fix PR c++/59635

On 2014-01-03 21:45, Adam Butcher wrote: * g++.dg/opt/pr59635.C: New testcase. s/opt/cpp1y/ +int (*p) (int, ...) = f; // { dg-error unimplemented } s/dg-error/dg-message/

[PATCH] Fix c++/59112 and c++/59113: Disallow implicit function templates in local functions unless defining a lambda.

gcc/cp/ PR c++/59112 PR c++/59113 * parser.c (cp_parser_parameter_declaration_clause): Disallow implicit function templates in local functions unless defining a lambda. gcc/testsuite/ PR c++/59112 PR c++/59113 g++.dg/cpp1y/pr58533.C: Updated

Re: [C++ PATCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.

On 2013-11-10 23:21, Jason Merrill wrote: On 11/10/2013 02:39 PM, Adam Butcher wrote: I assumed that tsubst simply doesn't do anything with a null tree substitution (i.e. it is an identity op). Substituting NULL_TREE for a template parameter gives a template parameter with a reduced level

Re: [C++ PATCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.

On 2013-11-10 6:10, Jason Merrill wrote: Hmm, actually I think messing with the non-pack's decl is dangerous, and we should come up with a new decl for the pack instead. I think you can use reduce_template_parm_level with a levels argument of 0 to build a new decl and parm index. I actually

Re: [C++ PATCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.

On 2013-11-10 10:38, Adam Butcher wrote: On 2013-11-10 6:10, Jason Merrill wrote: Hmm, actually I think messing with the non-pack's decl is dangerous, and we should come up with a new decl for the pack instead. I think you can use reduce_template_parm_level with a levels argument of 0

Re: [C++ PATCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.

On 2013-11-10 18:49, Jason Merrill wrote: On 11/10/2013 08:10 AM, Adam Butcher wrote: + /* Build up a tree vec of empty tree vecs up to the inner substitution +args built above. */ I think we want to copy the enclosing args; see existing uses of add_outermost_template_args

Re: [C++ PATCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.

On 2013-11-08 18:50, Jason Merrill wrote: On 10/31/2013 05:47 AM, Adam Butcher wrote: + become_template = true; + push_deferring_access_checks (dk_deferred); Why is this call here? I don't see anything in the rest of the function that would trigger an access check

Re: [C++ PATCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.

On 2013-11-09 13:21, Adam Butcher wrote: On 2013-11-08 18:50, Jason Merrill wrote: On 10/31/2013 05:47 AM, Adam Butcher wrote: + become_template = true; + push_deferring_access_checks (dk_deferred); Why is this call here? I don't see anything in the rest of the function

[C++ PATCH 2/3] Support implicit parameter packs.

* parser.c (convert_generic_types_to_packs): New function to transform a range of implicitly introduced non-pack template parms to be parameter packs. (cp_parser_parameter_declaration_list): If a function parameter pack contains generic types, convert them

Re: [SKETCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.

Hi Jason, I've got the tsubst solution for implicit parameter packs working now. I've also improved the efficiency of incremental template parameter synthesis and added some testcases. All C++14 generic lambda examples pass and no new regressions. Cheers, Adam Patch summary (3): Refactor

[C++ PATCH 3/3] Add some generic lambda test cases.

gcc/testsuite/g++.dg/cpp1y/ * lambda-generic.C: New test case. * lambda-generic-cfun.C: New test case. * lambda-generic-dep.C: New test case. * lambda-generic-udt.C: New test case. * lambda-generic-variadic.C: New

[C++ PATCH 1/3] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.

gcc/ * tree.c (grow_tree_vec_stat): New function ... * tree.h (grow_tree_vec_stat) (grow_tree_vec): ... and its declaration and macro front-end. gcc/cp/ PR c++/58534 PR c++/58536 PR c++/58548 PR c++/58549 PR c++/58637 *

Re: [SKETCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.

On Wed, 25 Sep 2013 11:01:26 -0500, Jason Merrill wrote: On 09/24/2013 02:05 AM, Adam Butcher wrote: On the subject of on-the-fly synthesis: I haven't started yet but I'm thinking to trigger in 'cp_parser_simple_type_specifier' when 'current_binding_level-kind == sk_function_parms

Re: [SKETCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.

On 2013-10-15 22:21, Adam Butcher wrote: On Wed, 25 Sep 2013 11:01:26 -0500, Jason Merrill wrote: 2) If we see 'auto', scan ahead (possibly via tentative parsing) to see if there's a ... My current preferred option. The problem with it is that, ideally, I only want to look ahead

Re: [SKETCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.

On 2013-10-11 3:26, Jason Merrill wrote: Can we put this in cp_parser, invert the sense of the flag, and only set it during cp_parser_parameter_declaration_clause? Done. But it still needs a flag to disable in the case of explicit template specialization. Can't you just check

Re: [SKETCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.

On 2013-10-09 4:37, Jason Merrill wrote: On 10/07/2013 05:14 AM, Adam Butcher wrote: + /* Forbid ambiguous implicit pack expansions by only allowing +a single generic type in such a parameter. +XXX: Maybe allow if explicitly specified

[SKETCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.

/pr58549.C | 10 ++ gcc/testsuite/g++.dg/cpp1y/pr58637.C | 7 + 8 files changed, 299 insertions(+), 106 deletions(-) commit 90c77cdd87eb63617719a9ad129803a2048761ff Author: Adam Butcher a...@jessamine.co.uk Date: Wed Sep 18 17:39:40 2013 +0100 Refactor implicit function template implementation

Re: [C++1y] [PATCH 3/4] ... canonical type workaround and refactoring

On 23.09.2013 08:15, Adam Butcher wrote: On 22.09.2013 18:57, Adam Butcher wrote: The following solves the canonical type issue in the general case (pointers and refs) and makes it equivalent to the explicit template case -- in terms of canonical type at least. for (tree t = TREE_TYPE

[C++1y] [Implicit Fix instantiation of implicit function template forward declarations.

Hi Jason, I noticed that, although implicit function template declarations were accepted. They weren't setup correctly and didn't instantiate properly. The following patch fixes this by moving finish_fully_implicit_template to the end of cp_parser_init_declarator. OK to go with the others?

[C++1y] [PATCH] Fix PR c++/58500

Hi, This fixes using 'auto' in the return type of a function pointer to introduce an implicit function template parameter. Note that this doesn't mean that 'auto' parameters in a function ptr will be treated the same; I think we need a special case for this in the implicit template

Re: [C++1y] [PATCH 3/4] Ensure implicit template parameters have distinct canonical types.

On 22.09.2013 18:57, Adam Butcher wrote: The following solves the canonical type issue in the general case (pointers and refs) and makes it equivalent to the explicit template case -- in terms of canonical type at least. for (tree t = TREE_TYPE (TREE_VALUE (p)); t; t = TREE_CHAIN (t

Re: [C++1y] [Implicit Fix instantiation of implicit function template forward declarations.

On 23.09.2013 19:03, Jason Merrill wrote: On 09/23/2013 01:53 AM, Adam Butcher wrote: + if (member_p) +decl = finish_fully_implicit_template (parser, decl); + else +finish_fully_implicit_template (parser, /*member_decl_opt=*/0); Why don't we want to return the template for the non

Re: [C++1y] [PATCH] Fix PR c++/58500

On 23.09.2013 19:02, Jason Merrill wrote: On 09/23/2013 02:08 AM, Adam Butcher wrote: Note that this doesn't mean that 'auto' parameters in a function ptr will be treated the same; I think we need a special case for this in the implicit template parameter introduction code (or refactor

Re: [C++1y] [PATCH 1/4] Use translation-unit-global rather than parameter-list-local counter for generic type names to facilitate nested implicit function templates.

On 20.09.2013 18:46, Jason Merrill wrote: On 09/19/2013 02:37 PM, Adam Butcher wrote: + static int i = 0; I think this needs to be global and GTY so that it works properly with PCH. Didn't consider PCH. This delta OK? --- a/gcc/cp/parser.c +++ b/gcc/cp/parser.c @@ -28897,12 +28897,12

Re: [C++1y] [PATCH 3/4] Ensure implicit template parameters have distinct canonical types.

On 20.09.2013 18:47, Jason Merrill wrote: Why is canonical_type_parameter not doing the right thing here? I don't see a reason we should need to treat these differently from normal template parms. The issue only happens with indirect parms. The type 'auto' is given a canonical type in

Re: [C++1y] [PATCH 3/4] Ensure implicit template parameters have distinct canonical types.

On 22.09.2013 14:07, Adam Butcher wrote: On 20.09.2013 18:47, Jason Merrill wrote: Why is canonical_type_parameter not doing the right thing here? I don't see a reason we should need to treat these differently from normal template parms. The issue only happens with indirect parms. The type

[C++1y] [PATCH 2/4] Support nested generic lambdas.

* lambda.c (maybe_add_lambda_conv_op): Don't check for instantiated callop in the case of generic lambdas. --- gcc/cp/lambda.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c index b04448b..2ffa7e0 100644 --- a/gcc/cp/lambda.c

[C++1y] [PATCH 0/4] Fixes and enhancements to generic lambdas and implicit function templates.

Hi all, The following series contain a few miscellaneous updates to generic lambdas and implicit function templates. [1/4]: Use translation-unit-global rather than parameter-list-local counter for generic type names to facilitate nested implicit function templates. Using

[C++1y] [PATCH 3/4] Ensure implicit template parameters have distinct canonical types.

* parser.c (add_implicit_template_parms): Set the canonical type of a generic parameter to be that of the newly generated type such that it is unique. --- gcc/cp/parser.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c index

[C++1y] [PATCH 4/4] Generate more intuitive name for 'auto' parameters.

* parser.c (make_generic_type_name): Spell generic type names 'autoN' rather than '__GenN'. --- gcc/cp/parser.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c index 148e2f2..a54496a 100644 --- a/gcc/cp/parser.c +++

[C++1y] [PATCH 1/4] Use translation-unit-global rather than parameter-list-local counter for generic type names to facilitate nested implicit function templates.

* parser.c (make_generic_type_name): Use static count rather than parameter and ... (add_implicit_template_parms): ... propagate interface change here. --- gcc/cp/parser.c | 25 ++--- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git

[PATCH, committed] * pt.c (make_auto_1): Use input_location rather than BUILTINS_LOCATION.

--- gcc/cp/pt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index 2ef160a..ed08dca 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -21041,7 +21041,7 @@ static tree make_auto_1 (tree name) { tree au = cxx_make_type (TEMPLATE_TYPE_PARM); -

[PATCH, re-committed] Support lambda templates.

From: abutcher abutcher@138bc75d-0d04-0410-961f-82ee72b054a4 * parser.c (cp_parser_lambda_declarator_opt): Accept template parameter list with std=c++1y or std=gnu++1y. (cp_parser_lambda_body): Don't call 'expand_or_defer_fn' for lambda call operator template to

[PATCH, re-committed] Support using 'auto' in a function parameter list to introduce an implicit template parameter.

From: abutcher abutcher@138bc75d-0d04-0410-961f-82ee72b054a4 gcc/cp/ * cp-tree.h (type_uses_auto_or_concept): Declare. (is_auto_or_concept): Declare. * decl.c (grokdeclarator): Allow 'auto' parameters in lambdas with -std=gnu++1y or -std=c++1y or, as a GNU

Re: C++ PATCH for c++/41933 (variadic lambda capture)

Excellent. This now supports the variadic generic lambda from the spec (albeit without the auto parameter pack) auto vglambda = [](auto printer) { // TODO: return [=](auto ... ts) // OK: ts is a function parameter pack return [=] typename... T (T ... ts) // OK: ts is a

Re: [PATCH, committed] * pt.c (make_auto_1): Use input_location rather than BUILTINS_LOCATION.

On 16.09.2013 09:02, Eric Botcazou wrote: --- gcc/cp/pt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index 2ef160a..ed08dca 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -21041,7 +21041,7 @@ static tree make_auto_1 (tree name) { tree au =

Re: [PATCH, committed] * pt.c (make_auto_1): Use input_location rather than BUILTINS_LOCATION.

On 16.09.2013 17:54, Eric Botcazou wrote: Apologies if this was out of context. This was a change suggested and reviewed by Jason (http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01114.html). Then don't repost it on gcc-patches, it is already available on gcc-cvs:

Re: Generic lambda and implicit function template commits reverted

Hi Jason, Could you cast your eyes over these changes please? I intend to roll them up into the appropriate patches. I will make sure I bootstrap and before-and-after the g++.dg testsuite before pushing next time! [PATCH 1/5] Fix uninitialized variables causing breakage with -Werror. Not

  1   2   >