From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57531 invoked by alias); 12 Jun 2019 03:46:11 -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 57522 invoked by uid 89); 12 Jun 2019 03:46:11 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=relief, friend X-HELO: mail-qk1-f177.google.com Received: from mail-qk1-f177.google.com (HELO mail-qk1-f177.google.com) (209.85.222.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Jun 2019 03:46:09 +0000 Received: by mail-qk1-f177.google.com with SMTP id t8so5455312qkt.1 for ; Tue, 11 Jun 2019 20:46:09 -0700 (PDT) Return-Path: Received: from [192.168.1.116] (209-6-216-142.s141.c3-0.smr-cbr1.sbo-smr.ma.cable.rcncustomer.com. [209.6.216.142]) by smtp.gmail.com with ESMTPSA id a21sm7475924qkg.47.2019.06.11.20.46.05 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jun 2019 20:46:06 -0700 (PDT) From: Jason Merrill Subject: Re: C++ PATCH to implement deferred parsing of noexcept-specifiers (c++/86476, c++/52869) To: Marek Polacek Cc: GCC Patches References: <20181219202731.GL21364@redhat.com> <90c62261-b25e-0611-696d-044d319571cc@redhat.com> <20190510192133.GC20687@redhat.com> <2a193c49-75c7-4407-1f1f-3748a69ab560@redhat.com> <20190604010137.GY5989@redhat.com> Message-ID: <6949597a-e84c-4b87-ec57-f0186b936101@redhat.com> Date: Wed, 12 Jun 2019 03:46:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190604010137.GY5989@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg00673.txt.bz2 On 6/3/19 9:01 PM, Marek Polacek wrote: > I sort of ended up going down a rathole, but then I realized we don't need to > delay parsing of noexcept-specifiers of member friend function declarations, > because they aren't members of the class. Where are you getting this from? I'm definitely sympathetic to the idea that noexcept-specifiers of friend functions shouldn't need to be complete-class contexts, but 10.3 doesn't make that distinction that I can see. > This was a huge relief because > member friend function declarations can be redeclared, so we'd have to make > sure to check if their noexcept-specifiers match. But member function decls > can't be redeclared. I updated the comment to better reflect why what I'm > doing there is correct, along with an assert. But then why do you still need this: > + /* We can't compare unparsed noexcept-specifiers. Save the decl > + and check this again after we've parsed the noexcept-specifiers > + for real. */ > + if (UNPARSED_NOEXCEPT_SPEC_P (new_exceptions)) > + { > + DEFARG_DECL (TREE_PURPOSE (new_exceptions)) = copy_decl (old_decl); > + return; > + } ? Jason