From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98297 invoked by alias); 3 Aug 2016 20:23:19 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 98264 invoked by uid 89); 3 Aug 2016 20:23:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=doh, anonymous, sk:anonymo X-HELO: mail-qt0-f180.google.com Received: from mail-qt0-f180.google.com (HELO mail-qt0-f180.google.com) (209.85.216.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 03 Aug 2016 20:23:17 +0000 Received: by mail-qt0-f180.google.com with SMTP id w38so150027419qtb.0 for ; Wed, 03 Aug 2016 13:23:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=duO3BWF6H7IWUXlVcwEobPqu01iN+mLfNC4ehDWATQA=; b=RJF1INnq+jNl3wYqHroHndP9kR3jW3HLIfOupmvCBGjFEIzbChn7UkmyfcMwglNgWX pJOt9UBO/xWjb0BYbZ0UjTke3x2Bqkgw8jS+Jnv+h9aqA/bNerRi3oAzmSI+VPsvXelh isTeooFPgBmKWq3bBpe/1MTSIFeTyn/aE2YkRQUlkpeo6xSqpxV5rP5V92suAAiZaJ4V GhvKuU6mdNiTWxDJ3BkfK3kDTeeRJZUFLt7nS9eHr/5pph7Xi+PdUzYejyEIujDjt1we bp7aqOp6eB8NQadjIq+bSbP9EbmkcQ5rbBl29HSJGoQzwlvtFTVOLSiYuLWnxnhCF3tx 9obA== X-Gm-Message-State: AEkoousHb3DsIjR7j8JipJvm2bxvZ5gWkQiqjDssEq2GXm0uey49zsAYH8RYUwOKY+E8pg== X-Received: by 10.200.47.253 with SMTP id m58mr2325462qta.60.1470255795230; Wed, 03 Aug 2016 13:23:15 -0700 (PDT) Received: from [192.168.0.26] (75-166-202-97.hlrn.qwest.net. [75.166.202.97]) by smtp.gmail.com with ESMTPSA id 62sm5080381qtg.14.2016.08.03.13.23.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Aug 2016 13:23:14 -0700 (PDT) Subject: Re: [PATCH] accept flexible arrays in struct in unions (c++/71912 - [6/7 regression]) To: Jason Merrill References: <57927079.5080400@gmail.com> <5793A6F4.2090900@gmail.com> <69dc2b8d-1841-92b7-20ed-6e0a899435f2@redhat.com> <579BE53E.7070002@gmail.com> <6a6e323e-dbbb-f903-2492-e8ed26e01d65@redhat.com> <579E5F1E.8060603@gmail.com> <57A109E6.8010809@gmail.com> <57A241B6.5070804@gmail.com> Cc: Gcc Patch List From: Martin Sebor Message-ID: <57A252B1.6050901@gmail.com> Date: Wed, 03 Aug 2016 20:23:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00243.txt.bz2 On 08/03/2016 02:01 PM, Jason Merrill wrote: > On Wed, Aug 3, 2016 at 3:10 PM, Martin Sebor 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 .) > >> 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(t)) anon->function_only_defined_in_anonymous_struct (); } I was hoping something like this was close to what someone (Andrew?) has been working on. Martin