On 05/14/2011 06:49 PM, Jason Merrill wrote:
On 05/14/2011 02:19 PM, Ville Voutilainen wrote:
Cool, thanks! I'm not quite sure whether there are ambiguities in the
case
of elaborate-specifiers, but I suppose those can be fixed later.
Good point. In the case that
!cp_parser_next_token_starts_cl
On 05/14/2011 02:19 PM, Ville Voutilainen wrote:
Cool, thanks! I'm not quite sure whether there are ambiguities in the case
of elaborate-specifiers, but I suppose those can be fixed later.
Good point. In the case that
!cp_parser_next_token_starts_class_definition_p, we should rewind to
befor
On 14 May 2011 21:15, Jason Merrill wrote:
> On 05/14/2011 12:42 PM, Ville Voutilainen wrote:
>> Duly noted, I'll keep that in mind for subsequent ones. Is the patch
>> otherwise ok?
> Yes, and I've applied it.
Cool, thanks! I'm not quite sure whether there are ambiguities in the case
of elaborat
On 05/14/2011 12:42 PM, Ville Voutilainen wrote:
On 14 May 2011 19:41, Jason Merrill wrote:
Paolo is right, C++0x tests go in cpp0x. I'll move this and your earlier
one.
Duly noted, I'll keep that in mind for subsequent ones. Is the patch
otherwise ok?
Yes, and I've applied it.
Jason
On 14 May 2011 19:41, Jason Merrill wrote:
> Paolo is right, C++0x tests go in cpp0x. I'll move this and your earlier
> one.
Duly noted, I'll keep that in mind for subsequent ones. Is the patch
otherwise ok?
On 05/14/2011 10:56 AM, Ville Voutilainen wrote:
At Sat, 14 May 2011 09:01:39 +0200,
Paolo Carlini wrote:
... I'm wondering if wouldn't be more appropriate for the new testcase to be in
/cpp0x, with a name like final.C
There are probably other tests there that need moving too,
if such moving
At Sat, 14 May 2011 09:01:39 +0200,
Paolo Carlini wrote:
> ... I'm wondering if wouldn't be more appropriate for the new testcase to be
> in /cpp0x, with a name like final.C
There are probably other tests there that need moving too,
if such moving is done. I don't have a strong opinion
either way
... I'm wondering if wouldn't be more appropriate for the new testcase to be in
/cpp0x, with a name like final.C
Paolo
At Fri, 13 May 2011 14:13:52 -0400,
Jason Merrill wrote:
> Yes, the order affects the handling of
> struct Undeclared final { };
> Add the error after the call to cp_parser_commit_to_tentative_parse, at
> which point we've decided that we're dealing with a class definition.
Here's a new patch. Ho
On 05/13/2011 01:53 PM, Ville Voutilainen wrote:
On 13 May 2011 20:46, Jason Merrill wrote:
Why did you put this before the invalid template-id check, rather than
after?
For no particular reason. Is it significant?
Yes, the order affects the handling of
struct Undeclared final { };
Also,
On 13 May 2011 20:46, Jason Merrill wrote:
> Why did you put this before the invalid template-id check, rather than
> after?
For no particular reason. Is it significant?
> Also, shouldn't we reject "override" on classes?
You can have stuff like
struct blah override{};
where struct blah is an e
On 05/13/2011 01:24 PM, Ville Voutilainen wrote:
+error ("cannot derive from from final base %qT in derived type %qT",
Let's use % here.
if (id)
-cp_parser_check_for_invalid_template_id (parser, id,
-type_start_token->location);
+
Tested on Linux/X86-32.
2011-05-13 Ville Voutilainen
Implement final on class.
* class.c (check_bases): Diagnose derivation from a final class.
* cp-tree.h (lang_type_class): Add is_final and adjust dummy.
* cp-tree.h (CLASSTYPE_FINAL): New.
*
13 matches
Mail list logo
