On 05/30/2014 01:36 PM, Paolo Carlini wrote:
3- I understand Core/1227 as including the case of the late return type
vs the parameters of generic lambdas, thus the rather heavy handed tweak
to cp_parser_lambda_declarator_opt, which appears to work under the
debugger (in the sense that for testcas
Hi,
On 05/30/2014 04:41 PM, Jason Merrill wrote:
On 05/30/2014 10:21 AM, Paolo Carlini wrote:
You also need to propagate the flag in a bunch of other places:
everywhere we call build_method_type_directly ought to cover it.
Agreed, I spotted a few places. What about build_function_type? I think
On 05/30/2014 10:21 AM, Paolo Carlini wrote:
You also need to propagate the flag in a bunch of other places:
everywhere we call build_method_type_directly ought to cover it.
Agreed, I spotted a few places. What about build_function_type? I think
it's the same issue, right?
Right, I was just th
Hi,
On 05/30/2014 04:13 PM, Jason Merrill wrote:
On 05/29/2014 03:17 PM, Paolo Carlini wrote:
I put together the below which already passes testing.
Thanks!
You are welcome. Let's finish this, then ;)
+ bool do_inject = this_type && !dependent_type_p (this_type);
!dependent_type_p
On 05/29/2014 03:17 PM, Paolo Carlini wrote:
I put together the below which already passes testing.
Thanks!
+ bool do_inject = this_type && !dependent_type_p (this_type);
!dependent_type_p should be !dependent_scope_p, or perhaps even
CLASS_TYPE_P. It should be OK to inject a this po
Hi again,
On 05/29/2014 03:34 PM, Jason Merrill wrote:
On 05/28/2014 01:06 PM, Paolo Carlini wrote:
Now, I got this "insane" idea: would it make sense to simply invert the
substitutions (args and return) unconditionally?
If we're going to change the order, I want to do it in a more correct,
Hi,
On 05/29/2014 03:34 PM, Jason Merrill wrote:
On 05/28/2014 01:06 PM, Paolo Carlini wrote:
Now, I got this "insane" idea: would it make sense to simply invert the
substitutions (args and return) unconditionally?
If we're going to change the order, I want to do it in a more correct,
rather
On 05/28/2014 01:06 PM, Paolo Carlini wrote:
Now, I got this "insane" idea: would it make sense to simply invert the
substitutions (args and return) unconditionally?
If we're going to change the order, I want to do it in a more correct,
rather than differently wrong, way. DR 1227 clarified th
On 05/28/2014 10:00 PM, Paolo Carlini wrote:
Hi again,
On 05/28/2014 07:06 PM, Paolo Carlini wrote:
(In case I would have also to double check something weird I was
seeing if the injection happens for all method types...)
In the meanwhile I investigated the reason of all those regressions I
wa
Hi again,
On 05/28/2014 07:06 PM, Paolo Carlini wrote:
(In case I would have also to double check something weird I was
seeing if the injection happens for all method types...)
In the meanwhile I investigated the reason of all those regressions I
was seeing when injecting in all METHOD_TYPEs: w
Hi,
On 05/28/2014 06:33 PM, Jason Merrill wrote:
On 05/28/2014 11:59 AM, Paolo Carlini wrote:
I see. Even not considering this issue, there are many regression if I
inject for all method types. I'm afraid the issue turns out to be much
more tricky than I hoped, I guess I'm going to unassign mys
On 05/28/2014 11:59 AM, Paolo Carlini wrote:
I see. Even not considering this issue, there are many regression if I
inject for all method types. I'm afraid the issue turns out to be much
more tricky than I hoped, I guess I'm going to unassign myself, for now,
and work on some other pending issues
Hi,
On 05/28/2014 05:49 PM, Jason Merrill wrote:
On 05/28/2014 11:38 AM, Paolo Carlini wrote:
But unconditionally doesn't work, without doing something more. For
example for the first test, as reported: when current_class_type is set
and equal to "struct X", class_of_this_parm is "struct X<
>"
On 05/28/2014 11:38 AM, Paolo Carlini wrote:
But unconditionally doesn't work, without doing something more. For
example for the first test, as reported: when current_class_type is set
and equal to "struct X", class_of_this_parm is "struct X<
>".
Right, it needs to be the substituted this para
Hi,
On 05/28/2014 05:14 PM, Jason Merrill wrote:
On 05/28/2014 06:15 AM, Paolo Carlini wrote:
+ bool do_inject = (!current_class_ref
+&& TREE_CODE (t) == METHOD_TYPE
+&& TREE_CODE (TREE_TYPE (t)) == DECLTYPE_TYPE);
Let's do this for any METHOD_TYPE; the decltype could
On 05/28/2014 06:15 AM, Paolo Carlini wrote:
+ bool do_inject = (!current_class_ref
+ && TREE_CODE (t) == METHOD_TYPE
+ && TREE_CODE (TREE_TYPE (t)) == DECLTYPE_TYPE);
Let's do this for any METHOD_TYPE; the decltype could be nested as a
template argument.
... turns out, I can avoid fiddling with in_decl (which, I realized, is
meant to be used for diagnostics). The below version also passes testing.
Thanks,
Paolo.
/
Index: cp/pt.c
===
--- cp/pt.c (revision 211
... if the approach makes sense, we want to pass a proper in_decl in one
more place, otherwise specializations are not handled (eg, K in the
testcase). Like the below, lightly tested so far.
Paolo.
///
Index: cp/pt.c
=
Hi,
On 05/27/2014 07:15 PM, Jason Merrill wrote:
I don't think this is the right place for the fix; why do we have a
dummy object at all? Doesn't maybe_dummy_object return
current_class_ref in this situation?
I see, thanks for the dummy object clarification.
Therefore, it seems to me that th
I don't think this is the right place for the fix; why do we have a
dummy object at all? Doesn't maybe_dummy_object return
current_class_ref in this situation?
Jason
Hi,
here, in order to accept the code without an explicit this->
qualification, I propose to simply notice that instance ==
current_class_type. Tested x86_64-linux.
Thanks!
Paolo.
/cp
2014-05-27 Paolo Carlini
PR c++/57543
* call.c (build_new_method_ca
21 matches
Mail list logo
