OK.
Jason
Hi,
On 04/28/2013 09:10 PM, Jason Merrill wrote:
On 04/27/2013 05:17 PM, Paolo Carlini wrote:
Assuming as obvious that we don't want to crash on it, the interesting
issue is whether we want the static_asserts to both fail or succeed: in
practice, a rather recent ICC I have at hand fails both; a
On 04/27/2013 05:17 PM, Paolo Carlini wrote:
Assuming as obvious that we don't want to crash on it, the interesting
issue is whether we want the static_asserts to both fail or succeed: in
practice, a rather recent ICC I have at hand fails both; a rather recent
clang++ passes both (consistently wi
Hi again,
On 04/27/2013 02:56 AM, Jason Merrill wrote:
Why should id_expression_or_member_access_p be false?
"declval().dummy" is a class member access (5.2.5) regardless of
what kind of member dummy is.
today I have been able to spend some more time on the issue, and I think
the attached furt
Hi
>Why should id_expression_or_member_access_p be false?
>"declval().dummy" is a class member access (5.2.5) regardless of
>what
>kind of member dummy is.
I see, thanks. Then I suppose that finish_decltype_type must be adjusted to
handle the COMPOUND_EXPR, I'll look into it.
Thanks again
Paolo
Why should id_expression_or_member_access_p be false?
"declval().dummy" is a class member access (5.2.5) regardless of what
kind of member dummy is.
Jason
Hi,
in this ICE on valid, finish_decltype_type doesn't handle a
COMPOUND_EXPR when the second argument,
id_expression_or_member_access_p, is true.
As analyzed by Jakub in the audit trail, at parsing time for the test
involving:
struct A3 { static const int dummy = 0; };
the *.dummy in
