On 06/22/2014 10:42 AM, Paolo Carlini wrote:
I think the below would be most of it. Today, however, I did some
archeology, noticed that we would essentially revert to pre-PR9278
behavior (thus, per its audit trail, make again unhappy some people in
the template metaprogramming world?!? Was that k
Hi,
On 06/15/2014 03:37 PM, Jason Merrill wrote:
On 06/15/2014 01:01 AM, Paolo Carlini wrote:
Committed... but, I don't think we are done yet, because it seems to me
that DR577 means that in C++11 mode we have to accept the typedef?!?
Hmm, apparently so. Might as well apply the DR to C++98 mo
On 15/06/14 15:37, Jason Merrill wrote:
On 06/15/2014 01:01 AM, Paolo Carlini wrote:
Committed... but, I don't think we are done yet, because it seems to me
that DR577 means that in C++11 mode we have to accept the typedef?!?
Hmm, apparently so. Might as well apply the DR to C++98 mode as well
On 06/15/2014 01:01 AM, Paolo Carlini wrote:
Committed... but, I don't think we are done yet, because it seems to me
that DR577 means that in C++11 mode we have to accept the typedef?!?
Hmm, apparently so. Might as well apply the DR to C++98 mode as well.
Jason
Hi,
On 06/15/2014 12:17 AM, Jason Merrill wrote:
OK, thanks. :)
Committed... but, I don't think we are done yet, because it seems to me
that DR577 means that in C++11 mode we have to accept the typedef?!?
That's what current icc does... (I thought the issue was only about
clearer diagnostic
OK, thanks. :)
Jason
Hi,
On 06/13/2014 08:11 PM, Jason Merrill wrote:
On 06/13/2014 01:45 PM, Paolo Carlini wrote:
But it doesn't work here, doesn't do anything fancy, it exactly prints
'v' and nothing else.
That seems to be a bug in type_to_string, which sees that "void"
starts with "v" and concludes that they
On 06/13/2014 01:45 PM, Paolo Carlini wrote:
But it doesn't work here, doesn't do anything fancy, it exactly prints
'v' and nothing else.
That seems to be a bug in type_to_string, which sees that "void" starts
with "v" and concludes that they are the same. Oops.
Jason
Hi,
On 06/13/2014 07:39 PM, Jason Merrill wrote:
On 06/13/2014 01:02 PM, Paolo Carlini wrote:
Don't strip_typedefs; the error message should name the typedef.
But then, are we going to just print 'v'?!? We want "typedef-name for
type 'v'"?!? We already have the caret exactly below the 'v'... P
On 06/13/2014 01:02 PM, Paolo Carlini wrote:
Don't strip_typedefs; the error message should name the typedef.
But then, are we going to just print 'v'?!? We want "typedef-name for
type 'v'"?!? We already have the caret exactly below the 'v'... Please
clarify which exact message you want to see.
On 06/13/2014 06:59 PM, Paolo Carlini wrote:
Hi,
On 06/13/2014 06:49 PM, Jason Merrill wrote:
On 06/13/2014 12:42 PM, Paolo Carlini wrote:
+ "invalid use of typedef-name for type %qT in "
+ "parameter declaration", strip_typedefs (type));
Don't strip_typedefs; the
Hi,
On 06/13/2014 06:49 PM, Jason Merrill wrote:
On 06/13/2014 12:42 PM, Paolo Carlini wrote:
+ "invalid use of typedef-name for type %qT in "
+ "parameter declaration", strip_typedefs (type));
Don't strip_typedefs; the error message should name the typedef.
But then
On 06/13/2014 12:42 PM, Paolo Carlini wrote:
+ "invalid use of typedef-name for type %qT in "
+ "parameter declaration", strip_typedefs (type));
Don't strip_typedefs; the error message should name the typedef.
Jason
Hi,
On 06/13/2014 06:09 PM, Jason Merrill wrote:
On 06/13/2014 06:58 AM, Paolo Carlini wrote:
+error_at (DECL_SOURCE_LOCATION (decl),
+ "invalid use of typedef-name for type "
+ "% in parameter declaration");
+ else if (cv_qualified_p (type))
+erro
On 06/13/2014 06:58 AM, Paolo Carlini wrote:
+ error_at (DECL_SOURCE_LOCATION (decl),
+ "invalid use of typedef-name for type "
+ "% in parameter declaration");
+ else if (cv_qualified_p (type))
+ error_at (DECL_SOURCE_LOCATION (
Hi again ;)
On 06/13/2014 12:20 PM, Paolo Carlini wrote:
... nope, sorry, the latter doesn't pass testing, accepts:
(void = 0)
and void2.C regresses. Thus I propose something conservative, like the
below.
.. or tackle directly void2.C and use:
if (type == void_type_node
... nope, sorry, the latter doesn't pass testing, accepts:
(void = 0)
and void2.C regresses. Thus I propose something conservative, like the
below.
Thanks,
Paolo.
///
Index: cp/decl.c
===
--- cp/decl.c (rev
Hi,
On 06/12/2014 11:20 PM, Jason Merrill wrote:
On 06/12/2014 03:14 PM, Paolo Carlini wrote:
... in terms of code proper, the below is much better, IMHO. Assuming,
as I understand, we have no reason to call the rather heavy same_type_p
when we already know that VOID_TYPE_P (type) is true...
On 06/12/2014 03:14 PM, Paolo Carlini wrote:
... in terms of code proper, the below is much better, IMHO. Assuming,
as I understand, we have no reason to call the rather heavy same_type_p
when we already know that VOID_TYPE_P (type) is true...
same_type_p is not so heavy since it just compares
... in terms of code proper, the below is much better, IMHO. Assuming,
as I understand, we have no reason to call the rather heavy same_type_p
when we already know that VOID_TYPE_P (type) is true...
Thanks,
Paolo.
//
Index: cp/decl.c
20 matches
Mail list logo
