From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id AE3393858C53 for ; Wed, 4 May 2022 20:03:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AE3393858C53 Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-60-MDHoNJD5O8W_KZERvNGjVQ-1; Wed, 04 May 2022 16:03:33 -0400 X-MC-Unique: MDHoNJD5O8W_KZERvNGjVQ-1 Received: by mail-qt1-f199.google.com with SMTP id j18-20020ac806d2000000b002f354e9bc9eso1850236qth.10 for ; Wed, 04 May 2022 13:03:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=y7axG8ZHfvw4DfFAygpvbVcalS56MB6ojIQHt/CNbTA=; b=Yd4wo3VxPnvg8/2nQ3vxpm6edA/lEOHTFjhLShxK9+fZbyIUpYwU6KwPJ42Cg87k7u gOP8zT/ds8sP6XvXqCLddVp33/0qdWpC+D6DGpmrXlKI0xkfif/pMuiBZkRHgjlDiUUc G3Av9ZfqUDNGfsfpLjtq8J+xigmFcdAW4UK67h7vK+4KRLravfdq1jJrptyLc62Rfm/n 9I9oFzGiLtKmsvgOMfVqxX7ptTMN5gK8TK99WiezKzvYQTgEWS21qfJ5pb14ckcTL6Bs ++tenkZCAZmscYlyE3Bq9ttwsaGS5wZKVK0sJxG8Wa1VUMGhAh5NWiGCgvdRp7TfKv4c tx2w== X-Gm-Message-State: AOAM5333GvrS1KKPRMy1hYh5qlKSrpJlUQUSt/hyYokv1ztorhAoMHni qiQWo1Nag8oAD9wPSl2Orad173TL5EYBSIY/s4lwaeyjTzSfB0aWgplvEBUmkSrdkz8xYCJ55n+ Gwn5JXXcOLr0UnmpPZQ== X-Received: by 2002:ac8:7d83:0:b0:2e1:eca2:afb0 with SMTP id c3-20020ac87d83000000b002e1eca2afb0mr20734127qtd.521.1651694612857; Wed, 04 May 2022 13:03:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw8yHZ9w5YK0sM8pZVePml/72G7ZYISJCTBWro0Bx3dPm3P701PPsqJlzEB8wZAJJbmYzLeMQ== X-Received: by 2002:ac8:7d83:0:b0:2e1:eca2:afb0 with SMTP id c3-20020ac87d83000000b002e1eca2afb0mr20734099qtd.521.1651694612562; Wed, 04 May 2022 13:03:32 -0700 (PDT) Received: from redhat.com ([2601:184:4780:4310::f826]) by smtp.gmail.com with ESMTPSA id k26-20020ac8479a000000b002f3bbad9e37sm8249qtq.91.2022.05.04.13.03.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 May 2022 13:03:32 -0700 (PDT) Date: Wed, 4 May 2022 16:03:30 -0400 From: Marek Polacek To: Jason Merrill Cc: GCC Patches Subject: Re: [PATCH] c++: wrong parse with functors [PR64679] Message-ID: References: <20220502161836.30852-1-polacek@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.1.5 (2021-12-30) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2022 20:03:41 -0000 On Tue, May 03, 2022 at 04:43:05PM -0400, Jason Merrill via Gcc-patches wrote: > On 5/2/22 12:18, Marek Polacek wrote: > > Consider > > > > struct F { > > F(int) {} > > F operator()(int) const { return *this; } > > }; > > > > and > > > > F(i)(0)(0); > > > > where we're supposed to first call the constructor and then invoke > > the operator() twice. However, we parse this as an init-declarator: > > "(i)" looks like a perfectly valid declarator, then we see an '(' and > > think it must be an initializer, so we commit and we're toast. > > How vexing! :-) Most vexing indeed! > > My > > fix is to look a little bit farther before deciding we've seen an > > initializer. > > > > This is only a half of c++/64679, the other part of the PR is unrelated: > > there the problem is that we are calling pushdecl while parsing > > tentatively (in cp_parser_parameter_declaration_list), which is bad. > > I don't know how to fix it though, maybe move the pushdecl call to > > grokparms? Tricky :(. > > Can we pop the parm decls when the tentative parse fails? Unfortunately no, we'll have already given a hard error when that happens. About to send a patch where I describe the problem in detail. > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > OK. Thanks! Marek