Re: [C++ Patch] PR 58980

2014-01-23 Thread Jason Merrill
On 01/22/2014 04:29 PM, Paolo Carlini wrote: On 01/22/2014 10:10 PM, Jason Merrill wrote: Yep, that's along the lines I was thinking of. But again, prev_scope is irrelevant here, so the new code shouldn't mention it at all. Well, in practice I have to mention it in the error_at itself. Why?

Re: [C++ Patch] PR 58980

2014-01-23 Thread Paolo Carlini
Hi, On 01/23/2014 03:05 PM, Jason Merrill wrote: On 01/22/2014 04:29 PM, Paolo Carlini wrote: On 01/22/2014 10:10 PM, Jason Merrill wrote: Yep, that's along the lines I was thinking of. But again, prev_scope is irrelevant here, so the new code shouldn't mention it at all. Well, in practice I

Re: [C++ Patch] PR 58980

2014-01-23 Thread Paolo Carlini
On 01/23/2014 04:01 PM, Paolo Carlini wrote: Hi, On 01/23/2014 03:05 PM, Jason Merrill wrote: On 01/22/2014 04:29 PM, Paolo Carlini wrote: On 01/22/2014 10:10 PM, Jason Merrill wrote: Yep, that's along the lines I was thinking of. But again, prev_scope is irrelevant here, so the new code

Re: [C++ Patch] PR 58980

2014-01-23 Thread Jason Merrill
On 01/23/2014 10:30 AM, Paolo Carlini wrote: To be clear if we use %qT with nested_name_specifier we get: 58980.C:5:8: error: ‘typename A template-parameter-1-1 ::B’ has not been declared which frankly seems suboptimal to me, both vs the non-template case and the use of typename. If you want

Re: [C++ Patch] PR 58980

2014-01-23 Thread Paolo Carlini
On 01/23/2014 04:50 PM, Jason Merrill wrote: On 01/23/2014 10:30 AM, Paolo Carlini wrote: To be clear if we use %qT with nested_name_specifier we get: 58980.C:5:8: error: ‘typename A template-parameter-1-1 ::B’ has not been declared which frankly seems suboptimal to me, both vs the

Re: [C++ Patch] PR 58980

2014-01-23 Thread Jason Merrill
OK, thanks. Jason

Re: [C++ Patch] PR 58980

2014-01-22 Thread Paolo Carlini
On 01/21/2014 04:16 PM, Paolo Carlini wrote: + if (TREE_CODE (child) == TYPENAME_TYPE) +return false; + Maybe we want instead to do if (WILDCARD_TYPE_P (child)) return false; (which also passes testing, of course). Thanks, Paolo.

Re: [C++ Patch] PR 58980

2014-01-22 Thread Jason Merrill
On 01/21/2014 09:55 AM, Jason Merrill wrote: I think I would prefer to change the child assert to be MAYBE_CLASS_TYPE_P rather than CLASS_TYPE_P. On second thought, no, I think we do want to specifically handle TYPENAME_TYPE. But I think we want a different error message; getting a

Re: [C++ Patch] PR 58980

2014-01-22 Thread Paolo Carlini
Hi, On 01/22/2014 06:13 PM, Jason Merrill wrote: On 01/21/2014 09:55 AM, Jason Merrill wrote: I think I would prefer to change the child assert to be MAYBE_CLASS_TYPE_P rather than CLASS_TYPE_P. On second thought, no, I think we do want to specifically handle TYPENAME_TYPE. But I think we

Re: [C++ Patch] PR 58980

2014-01-22 Thread Jason Merrill
-patches@gcc.gnu.org CC: Subject: Re: [C++ Patch] PR 58980 Hi, On 01/22/2014 06:13 PM, Jason Merrill wrote: On 01/21/2014 09:55 AM, Jason Merrill wrote: I think I would prefer to change the child assert to be MAYBE_CLASS_TYPE_P rather than CLASS_TYPE_P. On second thought, no, I think we do want

Re: [C++ Patch] PR 58980

2014-01-22 Thread Paolo Carlini
On 01/22/2014 10:10 PM, Jason Merrill wrote: Yep, that's along the lines I was thinking of. But again, prev_scope is irrelevant here, so the new code shouldn't mention it at all. Well, in practice I have to mention it in the error_at itself. Otherwise I'm finishing testing the below. Paolo.

[C++ Patch] PR 58980

2014-01-21 Thread Paolo Carlini
Hi, in this relatively serious ICE on invalid regression (we don't emit any sensible diagnostic before ICE-ing) the problem is that is_ancestor simply asserts that the second argument can be only a NAMESPACE_DECL or a CLASS_TYPE_P, whereas in the erroneous input at issue it's a

Re: [C++ Patch] PR 58980

2014-01-21 Thread Jason Merrill
I think I would prefer to change the child assert to be MAYBE_CLASS_TYPE_P rather than CLASS_TYPE_P. Jason

Re: [C++ Patch] PR 58980

2014-01-21 Thread Paolo Carlini
Hi, On 01/21/2014 03:55 PM, Jason Merrill wrote: I think I would prefer to change the child assert to be MAYBE_CLASS_TYPE_P rather than CLASS_TYPE_P. .. Ok, but then it seems to me that we have to explicitly handle the TYPENAME_TYPE case, otherwise we end up simply accepting the testcase