This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] accept flexible arrays in struct in unions (c++/71912 - [6/7 regression])


On Wed, Aug 3, 2016 at 4:23 PM, Martin Sebor <msebor@gmail.com> wrote:
> On 08/03/2016 02:01 PM, Jason Merrill wrote:
>> On Wed, Aug 3, 2016 at 3:10 PM, Martin Sebor <msebor@gmail.com> wrote:
>>>>>>
>>>>>> Do you have ideas about how to improve the naming?  Perhaps change
>>>>>> TYPE_ANONYMOUS_P to TYPE_NO_LINKAGE_NAME?
>>>>>
>>>>> I haven't thought about changing names but TYPE_NO_LINKAGE_NAME
>>>>> seems better than TYPE_ANONYMOUS_P.
>>>>
>>>> Or perhaps TYPE_UNNAMED_P.
>>>
>>> TYPE_UNNAMED_P would work but it wouldn't be a replacement for
>>> TYPE_ANONYMOUS_P.
>>>
>>> It sounds like TYPE_ANONYMOUS_P is the right name and the problem
>>> is that the value it returns isn't accurate until the full context
>>> to which it applies has been seen.
>>
>> I think you're thinking of ANON_AGGR_TYPE_P, which identifies
>> anonymous structs/unions; TYPE_ANONYMOUS_P identifies unnamed classes.
>
> Doh!  You're right.  I let the name confuse me again. Clearly
> TYPE_ANONYMOUS_P isn't the best name since it doesn't correspond
> to the C/C++ concept of an anonymous struct or union.  TYPE_UNNAMED
> would be better (the same can be said about the C++ diagnostics that
> refer to unnamed structs as <anonymous struct>.)

I'll make this change; sorry for the merge conflict it will cause.

>>> I wonder if the right solution to this class of problems (which
>>> are probably unavoidable in the front end as the tree is being
>>> constructed), is to design an API that prevents using these
>>> "unreliable" queries until they can return a reliable result.
>>
>> It would be possible to change ANON_AGGR_TYPE_P to require
>> COMPLETE_TYPE_P, but a lot of uses will need to be adjusted to avoid
>> crashing.
>
> No, crashing shouldn't happen.  It shouldn't be possible to call
> the function unless/until the node that represents the concept
> has been fully constructed. Using C++ syntax:
>
>   void foo (tree *t)
>   {
>     if (ANONYMOUS_STRUCT *anon = dynamic_cast<ANONYMOUS_STRUCT*>(t))
>       anon->function_only_defined_in_anonymous_struct ();
>   }
>
> I was hoping something like this was close to what someone (Andrew?)
> has been working on.

I think for a while he was working on changing trees to use
inheritance rather than a discriminated union, but don't think he is
anymore.

Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]