OK.
Jason
On 06/23/2011 06:05 PM, Jason Merrill wrote:
So we should be able to just reject nested anonymous aggregates and
not worry about how to make them work.
The below appears to work pretty well, regtests fine. I had to tweak the
existing error17.C, we don't emit anymore the warning about no members
On 06/23/2011 06:11 PM, Paolo Carlini wrote:
On 06/23/2011 06:05 PM, Jason Merrill wrote:
Actually, 9.5 says
A union of the form
union { member-specification } ;
is called an anonymous union; it defines an unnamed object of unnamed
type. The member-specification of an anonymous union shall o
On 06/23/2011 06:05 PM, Jason Merrill wrote:
Actually, 9.5 says
A union of the form
union { member-specification } ;
is called an anonymous union; it defines an unnamed object of unnamed
type. The member-specification of an anonymous union shall only define
non-static data members. [ Note: N
On 06/23/2011 06:01 PM, Jason Merrill wrote:
On 06/23/2011 11:52 AM, Paolo Carlini wrote:
Ok, then, from what you saying I understand that it should be possible
to actually construct a reject-valid or an ice-on-valid in this area,
isn't just about improving the diagnostic, that is only the tip o
Actually, 9.5 says
A union of the form
union { member-specification } ;
is called an anonymous union; it defines an unnamed object of unnamed
type. The member-specification of an anonymous union shall only define
non-static data members. [ Note: Nested types and functions cannot
be declared
On 06/23/2011 11:52 AM, Paolo Carlini wrote:
Ok, then, from what you saying I understand that it should be possible
to actually construct a reject-valid or an ice-on-valid in this area,
isn't just about improving the diagnostic, that is only the tip of the
iceberg, so to speak. I guess it's not f
On 06/23/2011 05:47 PM, Jason Merrill wrote:
Indeed. The code is using DECL_NAME in templates so that tsubst can
look them up again by name, but as we see in this PR that can't work
if the field has no name. We need a different strategy for handling
anonymous aggregates nested in other anonym
On 06/23/2011 11:30 AM, Paolo Carlini wrote:
Why are we creating a COMPONENT_REF with a null op1 in the first place?
As a matter of fact, the possibility that DECL_NAME (field) could be
null is considered in build_anon_union_vars itself, because right after
the above mentioned build_min_nt cal
Hi,
Why are we creating a COMPONENT_REF with a null op1 in the first place?
For now, what I figured out is the following: build_anon_union_vars
calls build_min_nt (COMPONENT_REF, object, DECL_NAME (field), NULL_TREE)
with a null third argument, which becomes the null op1.
As a matter of fact,
Why are we creating a COMPONENT_REF with a null op1 in the first place?
Jason
Hi,
a patchlet for a pretty old ice-on-invalid regression. Tested x86_64-linux.
Ok for mainline?
Thanks,
Paolo.
/cp
2011-06-23 Paolo Carlini
PR c++/44625
* pt.c (tsubst_copy_and_build): Do not use BASELINK_P on a NULL_TREE.
/testsuite
2011-06-23 Paolo Car
12 matches
Mail list logo
